HN Explorer

Functional programming: A step backward (javaworld.com)

14 points by Confusion ↗ HN
You could almost consider it trolling to submit this here. Rather than rehash a discussion of the advantages of functional programming, I would like the comments to focus on a specific issue this article exemplifies: why isn't functional programming catching on?

9 comments

[ 2.1 ms ] story [ 36.8 ms ] thread
Confusion
You could consider it trolling of me to submit this here. However, rather than rehash the discussion of the advantages of functional programming, I would like to focus on a specific issue this article exemplifies: why isn't functional programming catching on?

Why are these 'scary' code examples used as an indication of what 'functional programming' looks like, instead of entirely reasonable Ruby, javascript or even Java snippets? How is it that proponents continue to fail to make it clear that functional programming can be done, to some extent, in any language and that it still has advantages?

lextori
It is easier to pull out scary and obscure bits of code from languages that have arcane syntax. I'm sure that it'd be pretty easy to find some c++ code that is even more difficult to read.

The whole article seemed to me to be a big "waahh this is hard, and looks funny" rather than a serious discussion of the advantages and disadvantages of functional programming.

Lambdanaut
I agree. Also, the code examples were very poor in making any point. Coming from somebody with a functional background but with no Erlang experience, the Erlang was trivially clear to me in its purpose.

The Haskell would be much clearer if it wasn't missing a type signature.

sp332
I've been leaning heavily on functional programming in my Python code lately. I understand that Guido doesn't want Python to become a full-blown functional language. But I find that, at the very least, avoiding explicit loops makes my code easier to understand.
shoo
The author of the article does not appear to be a proponent of functional programming, or at least does not appear to be a proponent of the syntax used by a number of functional languages.

These code examples are used by the author of the article to support the point he is trying to make. I imagine these are probably pretty good examples to use for the target demographic of javaworld.

jonenst
This has to be a troll. Both snippets of code given in page 2 are pretty readable and self-documented. The author didn't provide an implementation of the same algorithm in an imperative language. I'd be ready to bet that the comparision wouldn't be to the advantage of the imperative language.
shoo
I feel that this is a good example of Rich Hickey's simple-vs-easy disjunction. If you are an experienced java programmer, then it is easy to understand code with a similar syntax to java. Code with a foreign syntax will be initially very difficult to understand, even if it has simpler semantics.
AlexandrB
I agree that the basic problem is familiarity. Even beyond syntax, OO code carries with it a certain set of idioms that are obvious to anyone versed in an OO language (e.g. instantiation). Likewise, functional programming has its own idioms that are not obvious to someone not versed in any functional language.
gkuan
Well, the author of the article called functional programming (FP) a "bandwagon" and cited how mainstream languages are incorporating FP features. This suggests to me that at least according to this author, FP is already "catching on" and probably more so than he prefers. Of course from the FP community's perspective, it still looks like an uphill battle.

About the 'scary' code examples, one is perfectly reasonable and the other is taken quite out of context. I think it is the case that one can always produce unreadable code regardless of language.

Proponents who are behind particular language and maybe even a specific compiler are promoting exactly those. Of course, FP-style can be used in any language that supports first-class functions, proper closures, and tail call optimization. There are plenty examples of mainstream languages with the first of those. The remainder are not as widespread. However, the advantages of many modern FP languages go well beyond that of the key features pioneered by LISP and the Landin's unimplemented language ISWIM from the 1960s. When people tout Haskell, they are probably not doing so just for the first-class functions. They probably are enamored by the sophisticated static type system, type classes, and many, many more important features which cannot be easily emulated in a mainstream language because they require language and compiler support. Another example: Because functional style often entails recursion, the lack of proper tail call optimization is a huge barrier.

The primary advantage of FP that the author of the article concedes is concurrency benefits from pure FP. Purity (statelessness) requires considerable language support. In most mainstream languages, state is just too pervasive to make any substantial purity guarantees for concurrency. FWIW, I think the jury is still out on the concurrency question in FP.

The fact is that many mainstream languages are becoming quite multi-paradigm. I think many in the FP community view that development positively. In the very least, ubiquity of some functional features will make it easier for people to transition to full-blown modern FP languages. However, having mainstream languages adopt just one or two features pioneered decades ago isn't entirely satisfactory. There is so much more in modern FP languages, but that is where the community splinters dramatically.

That said, obviously JavaScript is one of the most successful programming languages in history (with no slight intended towards any other mainstream language). The other mainstream languages have also achieved great success through many years of hard work. It is great that people are rediscovering FP there where appropriate. It should be interesting to see how these languages ultimately evolve.