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/