The Time Is Right For Functional Design Patterns

It isn't for Erlang. If you look at the history of Erlang the language was released and after it had been in use for a while the language design team went around, identified the design patterns in use and implemented them as behaviours - the OTP system.<p>Where design patterns go wrong is in being a description of how to build a wheel (so you don't have to redsign the wheel) - what you really want is a wheel (so you don't have to rebuild the wheel).

This blog speaks from my heart: maybe I managed to wrap my head around OOD and even tried some AOP, but in the end, as I am - in the most general sense - a data miner, I always crave for high-throughput and low resource consumption. Every language I looked into was the same: do it OO, and it is nice, but do it functional and it processes loads of data at much better speeds. I settled for Python and C because the combine a huge library with sufficient functional paradigms (and, with "goto"-like-statements, you can even do coroutines in C!). Now we have multi-cores and everybody is starting to look into how to program for them, with functional patterns being the most efficient to adapt for that hardware. I at least have the strong feeling that what this guy is saying is quite true. (Although I am disappointed that Erlang wasn't on his list, as I just picked that as my next target language to learn... :)).

I'm working on a message passing style RPC using Couch replication and state machine documents, it encourages idempotent responses in the server's async processes, which is similar to functional operation.

There's always the 'Functional Pearls' series