[idProQuo]

>Since when FP is high performance and better concurrency support?

Lately I've been going back and forth between taking Udacity's Intro to Parallel Programming course (using CUDA, a C++ extension) and reading Learn You A Haskell For Great Good. I've found that while FP principles are cool to think about, they're also crucial for writing proper concurrent code.

If you write a kernel (a function executed by many threads in parallel) that produces side effects, you'll end up with a mess (since you can make no assumption about which threads will get to a particular part at which time). Furthermore, when you design parallel algorithms, knowing how monoids work is useful: you want to be doing operations that are associative and have empty implementations (+0, *1, AND true, OR false) so that they can be run in any order.

In short, Haskell forces you to stop thinking about the order in which your commands will be run, which is also a constraint imposed by parallelism.

[taeric]

Of course, when you are coding in such a way that you know what all of your shared resources are, sometimes it is convenient to be the one in charge.

I pretty much always go to a cooking analogy. Knowing how many spoons/dishes/ovens/stovetops/etc is critical to specifying an algorithm for making a large dinner. In many kitchens, you even have to account for how long it takes to clean said items to know how many you will need.

Basically, when designing an algorithm (or recipe), I think I fully agree with what you are saying. When you are designing the plan of attack on how something will actually be done, you typically have to go lower.

Now, I fully expect/hope that that part of the task could be done mechanically. I think it is safe to say that compilers aren't as far as many advocates put forth.