The first thing that immediately lept out at me as I was reading this was that turning Futures into Functors is great if your future implementation understands that is how they are going to be used. I've seen several naive examples of concurrent Futures that would horribly break if used in this way. Heck, I've seen <i>good</i> future implementations that would execute that code sub-optimally.<p>To my eye, this article is a microcosm of the fundamental tension of scala. On the one hand, we have a mountain of stable code from the java world; on the other, a strong desire to leverage the more robust techniques of FP. Unfortunately, they have to be mixed with extreme care or you end up creating performance bottlenecks and breaking semantics.
Interesting article, though the title is a bit misleading. I'd say a better one would be "Design Patterns of Functional Languages" as the author is comparing common functional design patterns (monads, functors) to GoF OO design patterns. I think to explain to non-functional programmers the benefits of functional, you have to go beyond design patterns or showing them how you can make a compact loop with a single application of a "map" function. You gotta show them how treacherous side-effects are (especially as code size grows) and how the declarative nature of FP inherently creates highly modular code and flexible code!
> The use of Functors, Applicative and Monad (as well as other classes of types) is just like following the GoF design patterns.
How true: another set of tricky patterns, instead of just doing the simplest working thing. ;)
(Hint: dynamic languages render most of the patterns unnecessary - <a href="http://norvig.com/design-patterns/" rel="nofollow">http://norvig.com/design-patterns/</a> - and that also applies to functional programming)