[Haskell-cafe] Re: capture of idioms and patterns
jsnow at cs.pdx.edu
Fri Sep 24 03:21:35 EDT 2010
ajb at spamcop.net wrote:
> G'day all.
> Quoting Johannes Waldmann <waldmann at imn.htwk-leipzig.de>:
>> you got this backwards: what some folks call "idioms and (design)
>> actually *is* FP, because it is just this: higher order functions.
>> And it's been there some decades (lambda calculus).
>> That also explains the absence of any Design Patterns/Gang-of-Four
>> kind of book for Haskell - it's just not needed.
> Err... no.
> The phrase "design patterns" is a shorthand for "vocabulary of
> engineering experience". Zippers, continuation passing style, Church
> encoding... these are not what FP "is", but they are specific techniques
> that engineers working in Haskell need to know to use the language
An often-overlooked bit of trivia is that the first books on design
patters were not in computer science, but rather architecture. I would
recommend "A Pattern Language: Towns, Buildings, Construction" and "A
Timeless Way of Building" by Christopher Alexander to anyone who is
interested in a great example of how design patterns are supposed to
work (or anyone interested in constructing an attractive and functional
building). I've never read GoF (it seemed a bit too focused on
object-oriented design for my tastes), so I don't know how closely it
follows Alexander's conventions.
"A Pattern Language" is essentially a compilation of a couple hundred
patterns -- a great resource if you want to build a house, but it
doesn't offer much insight into what a pattern is. "A Timeless Way of
Building", on the other hand, describes what a pattern is and how to go
about discovering, documenting, and organizing (and, often, discarding)
I was initially skeptical of "patterns", as they seemed like a rather
vague concept, but it's actually quite formal. A pattern consists of
some context in which the pattern can apply, a conflict that arises
within that context, and a satisfactory solution to that conflict.
Described this way, a pattern is an idea that makes itself a target for
criticism, because a detractor can point out that the given pattern
doesn't apply to its context, or that it doesn't resolve the conflict,
or there may be some other pattern that works in a broader context that
fully covers the narrow context. However, this makes it much easier to
distinguish good ideas from bad ones.
One notion about patterns that I'm not sure whether the GoF authors were
aware of, is that the patterns can be arranged into a directed graph,
where the most general patters form a sort of root, and the more
specific, narrow patterns form the leaves. (Ideally, you would have a
tree, but you might not.) A common problem whether designing buildings
or programs, is that you get halfway into the design and have to start
over because you come across some constraint that can't be
circumvented. By starting with the most general patterns and working
down to the more specific ones, you can reduce the amount of
backtracking you will have to do.
> There is no GoF-like book for Haskell because it's not an idea that
> needs promoting in printed form. We just point people to the wiki.
> Andrew Bromage
I think a "functional design-pattern" section on the Haskell wiki would
be a good idea. I think the "patterns" framework is a good and useful
one, if we can communicate properly what design patters are and how
they're supposed to work. I think a lot of the basic knowledge about
functional programming patterns is already there, it just needs to be
Do people think this is the right way to document the Haskell
community's "oral tradition"?
More information about the Haskell-Cafe