Those are all good reasons why functional programming is an advantage. I guess you object to my grouping of all these under the "functional" umbrella term.

> In my opinion, the advantage of clojure by comparing it with Ruby are: - You get the best of Java (lots of library, OO)

I mention this as well, but that's not really an advantage over Ruby. JRuby gives you access to all the Java libraries you want.

Clojure Dude (talking to ruby dude): Hey, you should try clojure.

Ruby Dude: What is clojure ?

Clojure Dude: Oh, clojure is a lisp/functional language. You should really give it a try.

Ruby Dude: Why?

Clojure Dude: Its main advantage is that it's functional.

Ruby Dude: Wow, you convince me. I'm switching!

http://www.infoq.com/interviews/armstrong-peyton-jones-erlan...

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, in short.

It may be true that FP does make concurrency easier, but I don't think this has been demonstrated to be generally true yet and it's certainly not as simple as just eliminating side effects from your code.

What functional programming does mean right now is that it's much easier to chop your program up into reasonable-sized chunks: big enough that it's worth the overhead, small enough that you can distribute as widely as possible.

In other words, if you think of a functional program as a tree and then expect to run each leaf in its own thread, the overhead will vastly outweigh the benefits. But the functional semantics also allow you to run each of the dozen main branches in separate threads with little effort.

I do this in Clojure all the time.

I honestly think that the advantages of FP for concurrency will turn out to be relatively minor and that FP is more interesting as a means of improving code reuse and reducing bug counts. I'm not convinced that the current crop of FP languages are a win in those respects either though, taken as a whole.

Programming languages of the future need to enforce thread safety and mutation semantics as well as they do type safety. Functional programming is a step in that direction.

Nobody's necessarily claiming that a concurrent Clojure/Erlang/Haskell app is faster than concurrent C++/Java one, but they're definitely safer and easier to write.

Erlang does do that, more or less, although Erlang processes are much lighter weight than what we usually think of as a "process" or "thread".

Perhaps not generally true, but I think MapReduce and LINQ are two prominent examples of how a "functional programming-like" model lends itself to easy parallelization and distribution.

The 'FP makes concurrency easier' is a often-used selling point, but I think the jury is still out. First of all, many functional languages are impure, and do not have this advantage in the same manner that e.g. Haskell has. Second, purity can be an expensive trade-off due to the copying involved. For lots of things (e.g. fast linear algebra) you'll still want to work in an impure world.

I think a better selling point of some functional languages is clarity. For instance, some class of problems can be solved very elegantly in Haskell and ML using algebraic data types, pattern matching, etc. But then again, some other classes of problems can be solved elegantly in Prolog.

I'm curious -- were the programs that were easily parallelized with OpenMP largely data parallel to begin with? I haven't used OpenMP extensively, but I'd suspect that the ease of parallelizing a program with OpenMP probably varies inversely with the amount of explicit coordination/synchronization/update of shared state that the program requires.

But 'map' in MapReduce is also a typical data-parallel task.

[1] In practice, there is a trade-off: the vectors are usually so large for the average training set, that you do not really want to copy them for memory-efficiency, so the mapping and reduction are interleaved, requiring some locking.

To your second point, I made no claims that C and C++ are not used to solve performance intensive problems. I'm sure C and C++ (or Assembly, for that matter) can be applied to solve any number of problems, if that's one's calling.

Yes, I do realize that there are more applications of multicore processing than number crunching ;).

Examples of this other than Erlang?

With functional languages and "dumb" data you don't have to guess about what your data can do. You just do what you want with it.