[email protected] wrote:
G'day all.
Quoting Johannes Waldmann <[email protected]>:
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
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
