

A Bit of Heresy: Functional Languages are Overrated - kyleburton
http://www.benrady.com/2010/06/a-bit-of-heresy-functional-languages-are-overrated.html

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

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.

If the author has titled the post "Actors are Overrated" I might have agreed
with it.

~~~
Scriptor
Completely agree. The author mentions that he tried to learn Erlang and
Haskell (we don't know how much he tried), uses the technical specs of Haskell
and O'Caml, and then makes a side swat at Scala.

It looks like at the beginning of this year he had decided to learn Haskell as
a way to explore functional programming:
[http://www.benrady.com/2010/01/language-of-the-
year-2010.htm...](http://www.benrady.com/2010/01/language-of-the-
year-2010.html).

I simply don't think being unable to learn a language qualifies you to bash
it. It'd be more fitting for him to post about the first point in whatever
Haskell resource he is using where he became confused.

------
jerf
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 _program_ , 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 _you
can depend on them not being mutated_ , 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.

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.

The author isn't being anywhere near as contrary as I think he'd like....

~~~
cageface
The title of his article is that functional _languages_ are overrated and he
specifically points out that functional _techniques_ are available in other
languages, so I don't think you can say he's confusing the two concepts.

~~~
CodeMage
Yet he has a bias and it shows in his comments on Scala:

 _And if you're working in a hybrid language, what assurances do you have,
really, that your system is really thread safe? Indeed, the risk compentation
effect might give you a false sense of security, giving you a system that
actually had more concurrency problems that one written in a "dangerous"
language._

The phrase "hybrid language" in the original text is a hyperlink to Scala. By
author's own admission, the languages he has tried were Erlang and Haskell. He
hasn't mentioned either trying or not trying Scala, but the article seems to
imply the latter.

The problem with what he said is that he seems to be dismissing "hybrid"
languages like Scala as equally overrated or worse than pure functional
languages like Haskell. Just like Jerf pointed out, it's the paradigm that
matters more than the language. A language like Scala is designed to make FP
paradigm easy to do, without being a pure functional language. As far as I
know, it's not designed to make your programs "thread safe". I believe that
the author wouldn't have made his claim about "risk compensation" if he had
actually studied Scala and tried it out.

~~~
loup-vaillant
> Just like Jerf pointed out, it's the paradigm that matters more than the
> language.

Note however, that languages are extremely good at making us use their
prefered paradigm.

~~~
CodeMage
Which is why we have hybrid languages to help us combine paradigms.

------
yummyfajitas
_"The languages are just too complex, too terse, and absolutely full of
academic shitheaddery. I mean, seriously, what the hell."_

The author links to the _formal specification_ of Haskell and decides pattern
matching is "academic shitheaddery"?

Is the formal specification of Java any better?
[http://java.sun.com/docs/books/jls/third_edition/html/gramma...](http://java.sun.com/docs/books/jls/third_edition/html/grammars.html)

~~~
knieveltech
Java (being rife with academic shitheadery itself) may not have been the best
choice if you're trying to suggest the author doesn't have a point.

~~~
yummyfajitas
I picked Java because a) I know where to find it, b) the author mentions Java
positively and c) the C++ standard costs $18.

Any formal language spec will look ugly and hard to read. That's just the
nature of formal specs.

~~~
sprout
R5RS is a pretty light read.

------
cageface
In this interview: [http://www.infoq.com/interviews/armstrong-peyton-jones-
erlan...](http://www.infoq.com/interviews/armstrong-peyton-jones-erlang-
haskell)

Simon Peyton-Jones, the father of Haskell himself, dismisses the idea that
avoiding mutable state automatically buys you easy concurrency:

 _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,_

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.

~~~
loup-vaillant
Beware: you say "concurrent", but SPJ was talking about "parallel". Not
exactly the same.

~~~
cageface
"Concurrent" is the word he uses repeatedly. What distinction do you make
between "parallel" and "concurrent"?

~~~
loup-vaillant
"Concurrent" is about observable behaviour. Like with a web server, serving
many many requests concurrently. When SPJ is talking about concurrency, he is
most likely talking about shared state with software transactional memory.

"Parallel" is about optimizing an otherwise linear, or atomic program. Like
map-reduce, which can be run on a single CPU or on a distributed cluster. When
SPJ is talking about parallelism he is most likely talking about nested data
parallelism.

The distinction between the two can be made without ambiguity with the terms
"task parallelism" (concurrency), and "data parallelism" (parallelism).

~~~
cageface
_When SPJ is talking about concurrency, he is most likely talking about shared
state with software transactional memory._

If you read the interview he is talking about the kind of implicit concurrency
FP advocates often suggest you get for free with FP.

 _I suppose Haskell initially wasn't a concurrent language at all. It was a
purely functional language and we had the idea from the beginning that a
purely functional language was a good substrate for doing concurrency on. But
it turned out to be a lot harder to turn that into reality than I think we
really expected because we thought "If you got e1+e2 then you can evaluate e1
at the same time as e2 and everything will be wonderful because they can't
affect each other because it's pure."_

They had to add things like STM and explicit concurrency management because
_you don't get this for free just because you're doing FP_.

~~~
loup-vaillant
Oh. He says "concurrent" to talk about data parallelism. (Bayesian update in
progress…)

------
Zak
I'll speak to the languages I know here.

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.

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.

~~~
nostrademons
"Want to be sure certain parts of your program don't access
/dev/nuclear_missiles?"

Actually, if you want to make sure that parts of your program don't access
/dev/nuclear_missiles, I think that E is your language. In Haskell, it's as
easy as `unsafePerformIO $ hGetContents "/dev/nuclear_missiles"`, which at
least warns you that it's unsafe but doesn't really give any assurances
otherwise. And if you're in the IO monad anyway, you don't even need the
unsafePerformIO.

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

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

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.

~~~
yummyfajitas
_...what's wrong with Erlang?_

Strings:

    
    
        1> [98, 114, 111, 107, 101, 110] == "broken".
        true
    

Records are not real records, just compile time labels placed on top of
tuples. The syntax, seriously, three different line terminators?

Python and Haskell both make great go-to languages, and you can solve a wide
variety of problems in them. Erlang is the language you suffer with when you
truly need massive concurrency and distribution.

~~~
cageface
Haskell seems to have too many rough edges to make it nice for real-world
work. The inconsistent error handling (errors vs maybe vs either), weak record
syntax, and ruthlessly strict stance on mutability don't sound like things I
want to wrestle with on a large scale.

Scala, on the other hand, seems to strike more reasonable compromises on these
points and has all the java stuff to draw on when you need it.

~~~
kwantam
> inconsistent error handling

I don't understand how offering several choices is synonymous with
inconsistent. If you really really want "consistency", establish a policy for
your code and stick with it. All three have distinct uses, and each is better
for certain things than for others.

Anyhow, there's nothing particularly special about the Maybe or Either monads;
you should be able to easily implement either of those yourself, and calling
them a feature of the language---beyond the fact that they happen to be in the
standard library---is somewhat specious.

~~~
cageface
Error handling is one thing you want to have handled consistently across all
code, including third party libraries. I may be able to enforce a convention
in my own code but the typical app uses a dozen or more libraries.

[http://stackoverflow.com/questions/3077866/large-scale-
desig...](http://stackoverflow.com/questions/3077866/large-scale-design-in-
haskell/3083909#3083909)

~~~
Robin_Message
Consistent error handling is needed if you are returning 0 for success and -1
for failure. Or was it 1 for success and 0 for failure? But there's nothing
wrong with a type signature that precisely describes what you can get back.
Only argument I'd have with Either is it's not obvious which is the error
(although left is the convention and baked into the monad), although in
practice you'll be returning "Either ParseError ParseTree" which makes it
rather obvious. Also, do-notation over the Maybe monad is just perfect for
simple error handling, but sometimes you need to return more than None.
Happily, you can switch to Either without changing a great deal. But you can't
mix them easily, and that is a suckful thing about monads indeed.

~~~
cageface
So what do I do if I want to write a function that takes another function as a
parameter, and some of the possible functions use Maybe and some use Either?
What would this code look like?

~~~
yummyfajitas
f: (a -> m b) -> ... -> m Result

Maybe and Either are both monads and by convention Left errCode is the fail
method of the Either monad. This will work exactly as you think it should. It
will also work with, e.g., io actions that might fail.

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

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

------
dusklight
Why is our time being wasted with this article.

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.

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.

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

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

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

~~~
nirav
Unfortunately though, FP is being sold as panacea of concurrency problems, at
least in Java world.

I think that FP is much more than that, it actually helps me solve problems in
a very different and elegant way. I don't know how you classify this benefit
but for me it was analogous to solving a problem with recursion or loop; while
both can solve problems, recursion seems to be much more intuitive and elegant
way - Same for FP vs Imperative approaches.

~~~
vamsee
I'd agree to that, and solving problems in FP always made me think harder to
get an elegant solution. Though, it also means that you're uncomfortably close
to math. I think to fully exploit/understand FP, the programmer also needs to
be good at understanding the mathematical models/formulas behind FP.
Otherwise, I think he cannot truly exploit the potential of the tools he's
using. I haven't spent a lot of time doing FP to justify that opinion fully,
but whatever FP I did made me wish I took my math classes more seriously.

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

------
dkarl
_The languages are just too complex, too terse, and absolutely full of
academic shitheaddery. I mean, seriously, what the hell._

(Where "seriously" and "hell" are links to the Haskell and O'Caml language
documentation.)

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
_enough_ , but it would be so much nicer to actually understand stuff.

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

~~~
CodeMage
Do you honestly believe that? The history of programming is littered with
failed attempts to do that. For example, does "Microsoft Acess" ring any
bells?

The future of programming is definitely not to turn users into programmers.

~~~
loup-vaillant
Oh yes it is. Users should be programmers. All of them. Just so they can write
those little scripts. It's a question of independence.

You probably wanted to say that the future is not to dumb down programming to
the level of my "mom". I agree with that.

~~~
CodeMage
Maybe I have a weird family, but my mom does not want to write any scripts.
She just wants the damn thing to _work_.

For her and many other people I know, it's a bit like driving a car. If you
want to drive a car, you have to know certain basic rules and that's it. The
guys who do maintenance and repairs are the ones who know what happens under
the hood and you take your car to them whenever necessary.

I also know lots of people who know what happens under the hood and love to
tinker with their cars. I'm not one of them myself. I do that with computers,
but not with cars. I don't see why computers should be a special case where
everyone has to know how to tinker with the "stuff under the hood".

~~~
loup-vaillant
First, what we want an what's good for us are two different sets of things.
Especially when you don't have total information.

Second, programming does not always mean tinkering stuff "under the hood".
Advanced spreadsheets are front-end _and_ programming at the same time. Even
that:

    
    
      $ cat * | grep "groceries" | sort
    

is a program (though a rather trivial one). "Real" programs will still be
professional and hobbyist stuff. But scripting can be everyone's business.

Third, computers are fundamentally different from any other device: they are
general purpose. They can process any information you care to feed them, in
any way you care to program them to.

Finally, when our moms want to do something the computer can't presently do,
but could, they have 3 alternatives: give up, acquire a program that does the
job, or program it themselves. For many many jobs, acquire a program is the
only viable solution. But for small, specialized tasks, the existence of a
dedicated program is less likely. So if our moms want the damn thing to "just
work", they have no choice but to program it.

Knowing how to use computers (and the internet) is becoming as important as
knowing how to read. Because computers are general purpose machines, knowing
how to program them is an important part of knowing how to use them. It's a
big investment, but so is reading.

