I think the criticism here on GoF is misdirected.
As far as I'm concerned, GoF is (or at least should be treated as) a taxonomy, not a cookbook.
The fact that people use it as a cookbook is not necessarily the fault of the authors.
As far as I'm concerned, GoF is (or at least should be treated as) a taxonomy, not a cookbook.
The fact that people use it as a cookbook is not necessarily the fault of the authors.
That's pretty much what Alexander's books say.
The failure of GoF, in particular, is that people took it as a golden rule for every environment. IIRC, the examined source code was all object oriented c++ and smalltalk code. Yeah - it's not surprising that those patterns aren't going to work well in, say, Haskell.
+1
Back in the days of C when assembly was still important, calling conventions represented patterns that ensure the stack got cleaned up properly. We may no longer talk about it, it is still there, doing its work silently. The design patterns were harvested from a language that didn't support lisp-style macros or continuations or closures.
Patterns are helpful for people who have to work with particular languages, but are not particularly useful to language designers. But then, they [language designers] already know that.
It has a lot of examples which fold into one liners in dynamic languages or are simply "the way it could be done" instead of a pattern (they don't require additional code or attention - see abstract factory).