[Haskell-cafe] Re: capture of idioms and patterns

[Jim Snow]

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) 
>> patterns"
>> 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
> effectively.
>
> ...
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) 
them.

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.
>
> Cheers,
> 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 
formatted properly.

Do people think this is the right way to document the Haskell 
community's "oral tradition"?

-jim