Functional design patterns (was: How to get functional software engineering experience?)

[Ralf.Laemmel@cwi.nl]

Andrew J Bromage wrote:

> On the other hand, it's an exciting time to do engineering in
> declarative languages, because we can invent the design patterns and
> discover what the good habits are as we go along.

BTW, FP is older than OOP. So why are we so late :-) ?

Joost Visser and I, we worked out a few maybe not so obvious functional
programming patterns such as Success By Failure, Role Play, Rewrite Step,
Keyhole Operation just to mention a few. By not so obvious I mean that
they deal with generic programming rather than functional programming in
general.

     http://www.cs.vu.nl/Strafunski/dp-sf/

We use a certain FORMAT for design patterns, and there is some modest
analysis why this format is appropriate. Also, there is some discussion
why design patterns would do good for functional programming. This might
be interesting in the further process of accumulating design patterns
for functional programming.

I am in complete agreement with Jeffrey Palmer who wrote:

> From the research I've done to date, functional programming provides
> enough of a paradigm shift that there are significant new patterns/idioms

I have the feeling that the FP community has a hard time getting started
with design patterns. Part of the problem is that design patterns are
inherently "vague" and this is maybe something the authors in our field
do not like to consider. That is, if something is being written that is
meant to document design experience for functional programming, it ends
up being complex (say, "Stop programming this or that; you will definitely 
fall in love with Haskell if you can parse this article.").

Another more technical part of the problem is that it is not obvious what
format would be appropriate, especially because the driving ingredient of
an OO design pattern is the class hierarchy or an object structure, and
this does not make sense in a functional setting.

Yet another problem is that design patterns are all about design
and less about coding. Many challenges in functional programming are about
coding, and just about coding. We might need a different understanding
of what design patterns are because we would like to cover the rich
set of programming idioms in functional programming. I feel tempted to
say there aren't that many in OOP.

I guess there are more reasons why there is no GoF book out yet for FP.
But at least Jeffrey, Joost, and I, we are working on that :-)

Jeffrey Palmer wrote, too:

> To avoid any pattern debates: I personally believe that patterns are 
> especially useful for getting novices up to speed on concepts that
> might not be readily apparent at first glance.  Rather than treating
> patterns as anything "special" in their own right, for me they're simply
> a really convenient way of teaching people new and interesting concepts.

Why do you say this if you want to AVOID a debate ;-) ?

Design patterns are maybe convenient for teaching ...
But they are ESSENTIAL to gather design experience, and to regulate
the terminology in a field. They are also CRUCIAL for the interaction
of design and programming in the implementation phase, AND for the
idea of refactoring. Also, the idea of a design pattern catalogue
is just a kind of SELF-CHECKING notion to address all concerns a
programmer could possibly have. By self-checking I mean that the firm
adherence to a well-designed format for a catalogue is the key.

Ralf

-- 
Dr.-Ing. Ralf Laemmel
CWI & VU, Amsterdam, The Netherlands
http://www.cwi.nl/~ralf/
http://www.cs.vu.nl/~ralf/