Functional and Concurrency

This week I was at the QCon London conference (where I talked about Xtext extensively, but that's not the point here). Once again, an important topic was functional programming. As wel all know, the main driver for the hype around functional programming is the "end of the free lunch", in other words, since we'll all work with many many CPUs or cores, we have to deal with concurrency more explicitly. Just using the Quake Algorithm (suggested by Ted Neward: return to your cubible, wait for 18 months until Moore's law increases computer speed and then come back and claim to have improved the software) will not be sufficient.

So, the common wisdom is that once we do everything in a pure functional manner, there's no problem with concurrency, because there is no shared, mutable state. Hence no need for locking, hence no problem. Great.

However, using purely functional programming is also not very useful, since, if we allow no side effects, our program will do nothing except heat up the CPU ((c) Simon Peyton Jones, who talked about Haskell (to the Conference, and to me in an SE Radio interview, during which I think I actually understood monads).

Also, Erlang's great support for concurrency does not come from its functional nature. Rather, it is a consequence of its efficient implementation of the actor model: no shared state, only message passing between concurrent entities (the actors). It does not matter much whether *inside* an actor you're functional or not.

So here are the questions that are really important, and that I would like to see answered in a future talk on the functional/concurrency topic:

• if I use a nice, potentially sideeffect-free functional language (say: F#), what do I do with all the libraries (here: .NET) that are not functional?
  
• which parts of my system should I write in a functional language for good concurrency support, and where should I not do that?
  
• How much concurrency do I handle on platform/infrastructure-level (e.g. processes, EJBs, etc.) and how much do I handle on the language level? Which granularity is useful for which task?
  
• Also: Assuming the platform provides a concurrency model, what can the language do to make sure I cannot (or I am discouraged from) interfering with the platform's concurrency model?
  

So, functional and concurrency experts in the world, please unite! and write a bunch of (context,problem,solution,tradeoff)-tuples (also known as Patterns) and present them at a future JAOO or QCon conference. Or even better: if you are experienced here, contact me, so we can arrange for an SE Radio episode.  permalink