

Functional Programming (in Scala) for the rest of us - timf
http://www.tikalk.com/incubator/blog/functional-programming-scala-rest-us

======
KirinDave
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 _good_ future implementations that would execute that code
sub-optimally.

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.

------
mas644
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!

------
vseloved
> 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 -
> <http://norvig.com/design-patterns/> \- and that also applies to functional
> programming)

