[Haskell-cafe] Design Patterns by Gamma or equivalent
wren ng thornton
wren at freegeek.org
Tue Mar 17 00:09:37 EDT 2009
ajb at spamcop.net wrote:
> G'day all.
> Quoting wren ng thornton <wren at freegeek.org>:
> > Most of the (particular) problems OO design patterns solve are
> > non-issues in Haskell because the language is more expressive.
> ...and vice versa. Some of the "design patterns" that we use in
> Haskell, for example, are to overcome the fact that Haskell doesn't
> have mutable global state.
Oh sure. However, in my experience the most common design patterns of OO
are the ones obviated in functional languages. And I haven't tended to
need any of the global mutation patterns in Haskell. Not an objective
analysis by any means, but I do think it holds more water than it leaks.
The whole genre of SYB papers indicates that there's no panacea.
 The two times I've needed global mutation, one is for arbitrary
unique symbol generation (uses a library), and the other is for doing
some very tricky memoization with self-compaction when memory is low.
The latter I'd think is certainly too special-purpose to be considered a
> > A number of other patterns can
> > actually be written down once and for all (in higher-order functions
> > like foldr, map,...) instead of needing repetition.
> This is also true in many OO languages. A lot of the GoF book, for
> example, can be implemented as libraries in Ada or C++.
I think this depends very much on the specific language in question. For
dynamic OO languages with lambdas (Smalltalk, Ruby, Python, Perl) it's
easy, but then it's basically the same thing. For languages with a way
of doing mixins (the aforementioned, C++) it's also pretty easy. But for
languages like Java, oftentimes it's a choice between impossible and
grossly inefficient. I've been dealing with a lot of Java lately.
Certainly it's _possible_ to do in any language (Turing tarpit et al.),
but the question is one of how much boilerplate is involved and how
efficient it is. I think the latter point is important not only for the
projects I've worked on, but also for how widely adopted any given
pattern becomes; many people are fastidious about performance. The
former is also important to whether it gets spread as a "pattern" or
whether it gets packaged up in a library somewhere.
> > And then there are some things like monoids which fall somewhere
> > between idiom and pearl.
> "Things like monoids" are constructions from algebra.
> Abstract algebra and design patterns have a lot in common. They're
> based on the same idea, in fact: When a pattern keeps showing up,
> define it and give it a name so you can talk about it independently
> of any specific implementation.
> Or to put it another way, category theory is the pattern language of
Indeed. Though, IMO, there's a distinction between fairly banal things
(e.g. monoids), and the other more interesting bits of category theory
and abstract algebra. Monoids often occur by happenstance and so their
triviality lends to being more like an idiom. Similarly, functors also
tend to just happen. However, once you start getting into applicative
functors, natural transformations, and the like, you've made a step from
incidentally using a ubiquitous pattern of mathematics, to making a
concerted effort at abstraction.
More information about the Haskell-Cafe