A Bit of Heresy: Functional Languages are Overrated

A really incoherent article that's wrong in a lot of ways. The title is misleading because the author's main beef is with the idea that functional languages are the "solution" to the concurrency "problem." He admits that he's tried to learn both Erlang and Haskell and given up because the languages are too hard, too complex and "absolutely full of academic shitheaddery" and points to the reference manuals of Haskell and OCaml as proof (edit to add: Erlang is the opposite of "academic shitheaddery". Totally born and bred for business!). I might come off as an asshole for saying this, but if attempting to learn and then giving up on Erlang and Haskell is your only experience with functional languages then you're not in a position to comment on it. Keep digging into Haskell until you run into a Monad Transformer stack a mile long or spend some time with Clojure.<p>The author then conflates Actor based concurrency with functional programming in general. Let me lay my bias on the table right now: I'm sick to death of hearing about Actors. Erlang put them on the map and I think Scala made them popular, but Scala missed the point. Erlang's actors are only one piece of its distributed-ness; there's a lot more to Erlang that lets it scale as well as it does: a VM tuned for a large number of green threads, a transparent network stack, the supervisor model etc. Scala has none of these. Not only that, but actors themselves only solve one tiny problem in the world of concurrent (really, for actors, distributed) computing. They do nothing to address shared state. Finally, neither of these languages is really, truly functional.<p>If the author has titled the post "Actors are Overrated" I might have agreed with it.

The error here is confusing the language for the paradigm. He all but concedes that functional programming is a good idea and you can do it in current languages. True. When you do that, you have a functional program. The "functionalness" or "objectness" or "logicness" of a program is a characteristic of a <i>program</i>, not the implementation language. When you do object-oriented C, it isn't a "hack", it really is object-oriented C. You just don't have language support, you're doing objects by hand, with the corresponding disadvantages (syntactic pain) and advantages (no privileged concept of objects means you can do your own thing, which can be useful; want 'prototypes'? just do it! arguably easier in C than C++). When you do functional Javascript, it really is functional programming, you just don't have the same language support. When you refuse to mutate values and treat a language's values as immutable, even though the language permits you to mutate them, you have immutable values; the essense of immutable values is that <i>you can depend on them not being mutated</i>, not that the language makes it syntactically impossible to express mutation. This has obvious advantages if you want to use an immutable style, but is not strictly necessary.<p>Proof: It all ends up running on assembler anyhow, which isn't functional or OO or logical or any other paradigm. All of those things are categories of programs, not intrinsic attributes of the environment.<p>The author isn't being anywhere near as contrary as I think he'd like....

<i>"The languages are just too complex, too terse, and absolutely full of academic shitheaddery. I mean, seriously, what the hell."</i><p>The author links to the <i>formal specification</i> of Haskell and decides pattern matching is "academic shitheaddery"?<p>Is the formal specification of Java any better? <a href="http://java.sun.com/docs/books/jls/third_edition/html/grammars.html" rel="nofollow">http://java.sun.com/docs/books/jls/third_edition/html/gramma...</a>

In this interview: <a href="http://www.infoq.com/interviews/armstrong-peyton-jones-erlang-haskell" rel="nofollow">http://www.infoq.com/interviews/armstrong-peyton-jones-erlan...</a><p>Simon Peyton-Jones, the father of Haskell himself, dismisses the idea that avoiding mutable state automatically buys you easy concurrency:<p><i>But it turned out to be very hard to turn that into actual wall clock speedups on processes, leaving aside all issues of robustness or that kind of stuff, because if you do that style of concurrency you get lots of very tiny fine-grained processes and you get no locality and you get very difficult scheduling problems. The overheads overwhelm the benefits,</i><p>There are some useful and novel ideas in the FP languages but they're no silver bullet. Whatever the conventional solution for concurrent programming turns out to be, it will have to be exploited in languages more accessible to the median programmer than Haskell.

I'll speak to the languages I know here.<p>Haskell is a research language. It has become usable for practical purposes, but at heart its still a research language. Haskell focuses on isolating side effects over practicality or ease of use. For certain classes of problems, that turns out to be the most practical thing. Want to be sure certain parts of your program don't access /dev/nuclear_missiles? Haskell is your language. Is your app mainly centered around a complex GUI? Maybe you should look elsewhere.<p>I notice no mentions of Clojure in the article aside from including it in a list of functional languages. Clojure is a practical language designed for getting stuff done. It offers the most comprehensive solution for managing shared state I've seen in any language and does its best to get out of your way.

If you think shared state is hard to scale and you are arguing for message passing, then what's wrong with Erlang? In fact, you can't conflate Erlang, Haskell, O'Caml and Scala together as FP.<p>By being immutable by default, FP makes message passing simpler and in some cases forces you not to do shared state, so FP helps you do concurrency that way. Closures are old news and are in almost everything now anyway (I'd include Java anonymous inner classes, they just have a nasty syntax, although good for grouping methods, e.g. mouse events).<p>Other than immutability by default and closures, what makes a language functional anyway? Because if you take the languages you suggested together, that's all I see them having in common.

Im all for heresy, even though i don't agree with the author, his heresy is useful, we must avoid programming religions. It at least helped me understand a cultural problem programmers have at the moment with FP. The downfall of OOP was that it was misunderstood by all the imperative programmers. Even though it was adopted, it was misused. The downfall of FP will be that it is misunderstood by all the oo programmers, if it gets adopted it will get misused.<p>I never found FP hard to learn or use. I know now that it was because when i got introduced to it, i only had about a year of imperative programming experience and no OO experience at all. I was a rather fresh mind. My advice to all OO programmers willing to learn FP is to approach it with a fresh mind, it may save you a lot of headaches. Imagine you know nothing about programming, you may be surprised how close to the truth that is for some of us(including me).

Why is our time being wasted with this article.<p>The author himself says that he is too dumb to understand functional languages. He knows so little that he keeps carping on about concurrency, when that is nowhere near any of the central reasons why functional is valuable. Better support for concurrency is an accident, a side-effect. What makes functional important is the ability to create living abstractions, and understanding how functional allows you to do that and why it is important makes you a better programmer in any language.<p>There is no heresy here, only ignorance. The author is basically saying functional languages are "overrated" because he is unable to understand them. There are definitely valid arguments to be made against the functional paradigm, but he has made none of them.

&#62; I think the downfall of some of these languages is that they get wrapped up in being "functional" rather than focusing on solving a particular class of problem. They abandon convention and common sense for complex type systems and functional purity.<p>He's obviously not really looked at Clojure, then. The design philosophy of Clojure can be summarized as "functional programming is great; people also need to get stuff done."

I don't think FP is all about concurrency - it's about more than that. In my experience it reduces the possible bugs in code (type inference / checking, referential transparency) - these aspects make concurrency easier to achieve, but that's not all there is to FP.

I would have loved this if the blog post contained more technical details and some code snippets about the tradeoffs involved. Functional languages cover a broad spectrum. There are often multiple concepts being explored in a language, then there is the issue of cultural heritage of the respective communities, and the fact that FP languages have traditionally had multiple implementations with different tradeoffs. as an example -&#62; lisp and scheme are functional without being immutable. scheme favors a small spec while lisp includes large number of inbuilt primitives. Clojure introduces persistent datastructures and interesting new concepts like agents and integration with the jvm. I know too little about haskell and ML to make any informed comments about them but they appear espouse static typing unlike lisp / scheme. So if you have a particular beef about a functional language, look further and you will find one that doesnt share those traits.

<i>The languages are just too complex, too terse, and absolutely full of academic shitheaddery. I mean, seriously, what the hell.</i><p>(Where "seriously" and "hell" are links to the Haskell and O'Caml language documentation.)<p>God oh god I wish every language I used could be specified as precisely as the Haskell example. I didn't bother figuring out what the notation meant, but if I used Haskell, I could afford the time to understand it. Seriously, Perl and C++ have equivalent complexities; you just aren't expected to understand them. Experienced programmers steer clear of unfamiliar constructs, which works well <i>enough</i>, but it would be so much nicer to actually understand stuff.

The future of programming is when both my mum and my little brother can write small code that does some particular task for them. Neither of them will ever understand functional programming. That's basically the answer to what paradigm will win.