

The Time Is Right For Functional Design Patterns - bgray
http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2010-10.html#e2010-10-30T13_01_58.htm

======
gordonguthrie
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.

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).

------
fnl
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... :)).

------
jchrisa
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.

~~~
substack
RPC is a domain where functional patterns really shine since the high-latency
nature of network traffic is well suited to asynchronous, callback-oriented
event systems which are themselves inherently functional.

My own RPC system enforces continuation passing style exclusively to unify the
calling and return-value semantics. With this functional pattern in place it
was pretty straight forward to transparently wrap arbitrarily many closures
arbitrarily deeply in callback argument lists and method requests (which are
the same thing under continuation passing style).

------
kittenparade
There's always the 'Functional Pearls' series

