[Haskell-cafe] Design Patterns by Gamma or equivalent

[Gregg Reynolds]

2009/3/11 Mark Spezzano <mark.spezzano at chariot.net.au>:
> I’m very familiar with the concept of Design Patterns for OOP in Java and
> C++. They’re basically a way of fitting components of a program so that
> objects/classes fit together nicely like Lego blocks and it’s useful because
> it also provides a common “language” to talk about concepts, like Abstract
> Factory, or an Observer to other programmers. In this way one programmer can
> instantly get a feel what another programmer is talking about even though
> the concepts are fundamentally abstract.
>
> Because Haskell is not OO, it is functional, I was wondering if there is
> some kind of analogous “design pattern”/”template” type concept that
> describe commonly used functions that can be “factored out” in a general
> sense to provide the same kind of usefulness that Design Patterns do for
> OOP. Basically I’m asking if there are any kinds of “common denominator”
>  function compositions that are used again and again to solve problems. If
> so, what are they called?
>

You might find it useful to read the original works upon which the
whole "design pattern" economy is based, namely Christopher
Alexander's books
(http://www.patternlanguage.com/leveltwo/booksframe.htm?/leveltwo/../bookstore/bookstore.htm).
 I liked "Notes on the Synthesis of Form", which predates his pattern
language stuff.

My $0.02:  design patterns became popular in the imperative language
community precisely because such languages lack the formal discipline
of functional languages.  Alexander came up with the notion of a
pattern language in order to bring some kind of discipline and
abstraction to observed regularities in architecture, urban design,
etc.  By definition such a language cannot have anything close to
formal semantics, any more than a natural language lexicon can have
formal semantics.  Alexander's writing is very interesting and thought
provoking, but I'm not sure it has much to offer the world of
functional programming.

Programmers used Alexander's ideas to try to bring some order to both
specifications and programs.  A pattern language is a natural for
trying to describe a real-world problem one is trying to solve.
Imperative programmers also used it to describe programming patterns.
Implementations of things like Observer/VIsitor etc. are ad-hoc,
informal constructions; the equivalent in a functional language is a
mathematical structure (feel free to fix my terminology).  I don't
think one needs design patterns for Haskell; it has mathematics and
more-or-less formal semantics.  Who needs "Visitor" when you have "For
All"?  Although design patterns may still be useful for describing a
real-world problems I suspect one would be better off dumping the
notion of design pattern, the better to avoid cognitive dissonance
when trying to think in purely functional terms.

Cheers,
-gregg