4 ms·

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

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.

eropple 15y ago
Agreed. The GoF's stuff is descriptive, not prescriptive. You'll always get the occasional zealots going "no no, you must slather your code in Servants and Visitors", but...they're not the GoF, and who cares what they say?
ap22213 15y ago
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.
- teyc 15y ago
  | 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.
- viraptor 15y ago
  True, they won't work everywhere that well. There's another presentation from Peter Norvig: http://norvig.com/design-patterns/ppframe.htm http://norvig.com/design-patterns/ppframe.htm 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).

eropple 15y ago

Agreed. The GoF's stuff is descriptive, not prescriptive. You'll always get the occasional zealots going "no no, you must slather your code in Servants and Visitors", but...they're not the GoF, and who cares what they say?

ap22213 15y ago

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.

teyc 15y ago
| 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.
viraptor 15y ago
True, they won't work everywhere that well. There's another presentation from Peter Norvig: http://norvig.com/design-patterns/ppframe.htm http://norvig.com/design-patterns/ppframe.htm 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).