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.
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....
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.
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....
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.
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...
Any formal language spec will look ugly and hard to read. That's just the nature of formal specs.
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.
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.
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.
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.
Strings:
1> [98, 114, 111, 107, 101, 110] == "broken".
true
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.
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.
If Erlang is suffering, why has no-one written a better front end compiler with saner syntax or a static type system?
Now admittedly the programming models in HPC were ugly (MPI), but nevertheless the lack of shared state and the use of message passing certainly didn't make it easy to write high performance parallel apps.
I think the problem is fundamentally hard. And when a problem is fundamentally hard the solution to it often is "that other thing we haven't really tried yet". Until you've really tried it.
For most business processes, you don't care about performance all that much, you just want things to be easy to change. Message-passing works fairly well for that: it's easy to understand, composable, and let's you swap out one component for another as long as the interfaces are compatible.
BTW, message-passing isn't exactly untried. It's the basis for the service-oriented architectures that underlie Google, Amazon, FaceBook, and many other large businesses. It works very well for that problem domain.
Also, is their situation analogous to multicore today? i.e. does many GB of RAM shared by many cores count as "large-scale shared memory" (or does it not, e.g. because of cache effects)?
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).
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.
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 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.
(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.
No silver bullet. Getting computers to run code correctly (for whatever version of 'correct' you subscribe to) is hard, there is simply no way round this.
It's almost like saying 'the future of engineering is when both my mum and my little brother can build cars. Neither of them will ever understand mechanics.'
When you think of it that way, the idea that programming is for everyone seems a little silly.
What makes you think so? What fundamental complexity in the paradigm is out of their reach? Do you really think that the concepts of imperative and OO programming are simpler? Why?
The future of programming is definitely not to turn users into programmers.
I'm not suggesting that everyone will ever be able to implement quicksort or write a parser, but there is no fundamental reason that high-level programming will always be inaccessible to the masses.
You probably wanted to say that the future is not to dumb down programming to the level of my "mom". I agree with that.