

Functional programming: A step backward - Confusion
http://www.javaworld.com/javaworld/jw-07-2012/120705-what-s-wrong-with-functional-programming.html
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?
======
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.

------
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.

------
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.

