The GoF value isn't in being a taxonomy. It's about noticing that given certain environmental conditions and a goal, people will derive similar solutions. Patterns are just time-savers. So, if you see X, then do Y, because it will just work.
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.
| The failure of GoF, in particular, is that people took it as a golden rule for every environment
+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).
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.