TITLE: The Time is Right for Functional Design Patterns
AUTHOR: Eugene Wallingford
DATE: October 30, 2010  1:01 PM
DESC: 
-----
BODY:
Back in 1998, I documented some of the ideas that I used
to teach functional programming in Scheme.  The result
was the beginnings of a small pattern language I called
<A HREF="http://www.cs.uni.edu/~wallingf/patterns/recursion.html">
   Roundabout</A>.
When I workshopped this paper at PLoP, I had a lot of
fun, but it was a challenge.  My workshop consisted of
professional developers, most working in Java, with
little or no experience in Scheme.  Worse, many had been
exposed to Lisp as undergraduates and had had negative
experiences.  Even though they all seemed open to my
paper, subconsciously their eyes and ears were closed.

We gathered over lunch so that I could teach a quick
primer on how to read Scheme.  The workshop went well,
and I received much useful feedback.

Still, that wasn't the audience for Roundabout.  They
were are OO programmers.  To the extent they were looking
for patterns to use, they were looking for GoF-style
OO patterns, C++, Java, and enterprise patterns.  I had
a hard time finding an audience for Roundabout.  Most
folks in the OO world weren't ready yet; they were still
trying to learn how to do OOD and OOP really well.  I
gave a short talk on how I use Roundabout in class at
an ICFP workshop, but the folks there already knew these
patterns well, and most were beyond the novice level at
which they live.  Besides, the functional programming
world
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2007-07.html#e2007-07-27T18_58_15.htm">
   wasn't all that keen</A>
on the idea of patterns at all, not patterns in the style
of Christopher Alexander.

Fast forward to 2010.  We now have Scala and Clojure on
the JVM.  A local developer I know is working hard to
wrap his head around FP.  Last week, he sent me a link
to an InfoQ talk by Aino Corry on
<A HREF="http://www.infoq.com/presentations/Functional-Design-Patterns">
   Functional Design Patterns</A>.
The talk is about patterns more generally, what they are
and how GoF patterns fit in the functional programming
world.  At about the 19:00 mark, she mentions...
Roundabout!  My colleague is surprised to hear my name
and tweets his excitement.

My work on functional design patterns is resurfacing.
Why?  The world is changing.  With Scala and Clojure
poised to make noise in the Java enterprise world,
functional programming is here.  People are talking
about Scheme and especially Haskell again.  Functional
programming is trendy now, with famous OO consultants
talking it up and making the rounds at conferences and
workshops giving talks about how important it is.
(Some folks have been saying that for a while...)

The software patterns "movement" grew out of a need
felt by many programmers around the world to learn how
to do OO design and programming.  Most had been weaned
on traditional procedural programming and built up
years of experience programming in that style, only
to find that their experience didn't transfer smoothly
into the OO world.  Patterns were an ideal vehicle for
documenting OO expertise and communicating it to
programmers as they learned the new style.

We now face a similar transition in industry and even
academia, as languages like Scala and Clojure begin to
change how professionals build their systems.  They are
again finding that their experience -- now with OO --
does not transfer into the functional world without a
few hitches.  What we need now are papers that document
functional design and programming patterns, both at the
most basic level (like Roundabout) and at a higher
level (like GoF).  We have some starting points from
which to begin the journey.  There has been some good
work done on
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2007-11.html#e2007-11-02T13_24_45.htm">
   refactoring functional-style programs</A>,
and refactoring is a complement to patterns.

This is a great opportunity for experienced functional
programmers to teach their style to a large new
audience that now has incentive to learn it.  This is
also a great opportunity to demonstrate again the value
of the software pattern as a form for documenting and
teaching how to build things.  The question is, what
to do next.
-----