The most misunderstood book in CS
kawagner.blogspot.com
kawagner.blogspot.com
(Whenever a post comes up defending Design Patterns, it's also obligatory that someone pull out this link: http://blog.plover.com/prog/design-patterns.html .)
The author is perfectly right to say that interpreting a book which catalogues patterns in existing software as a prescription for how to implement new software is a great misunderstanding, as you've demonstrated in the post above.
"Norvig once wrote that the existence of design patterns is a sign of weakness in a language. I think he was wrong there. Sure, certain patterns are only necessary because a language don't allow to archive a certain goal directly by some build-in concept. But if you build it in, you would quickly discover other patterns 'a level above' instead of getting rid of those pesky design patterns. So we always have patterns, it's simply unadvoidable."
The problem is when you have to "hand-compile" a pattern repeatedly because the language doesn't let you abstract it away. Closures and macros let you codify most of those patterns once and for all.
"A concrete example: Java uses the "Iterator pattern" quite frequently. Now in functional programming this pattern is quite useless. We simply write map and fold functions and don't need no "iterator". Hah! But hey, isn't "writing a map and a fold function" not also a design pattern? All we need to do is to call it the "map and fold"-pattern. Using this pattern is common knowledge for every user of functional programming languages - so it's good to teach this pattern novices in functional programming right from the beginning."
But I don't have to reimplement map and fold every time I need to use it, I just need to call it. Whereas most of the time what we call a "design pattern" is something you have to reimplement all across the system by hand.
Here is why: suppose we have a programming knowing Java. We teach him ML. Then we teach him the design pattern book. He will have one revelation. ML. On the other hand, suppose we teach him the design pattern book and then teach him ML. He will have two revelations. "Strategy pattern? Why don't you just pass a higher order function... oh ... you can't do that easily ... maybe with an anonymous class .... hmm ... too verbose".
Now, apply that time is the most important commodity. You'll be working as hard to learn ML with or without the GOF book under your belt. But with ML under the belt, you'll soar through the GOF-book. Interesting, isn't it?
Just look at the most recent abomination in the NYT article on trolling:
"Technology, apparently, does more than harness the wisdom of the crowd. It can intensify its hatred as well."
That doesn't even make sense.
"No, we shouldn't add an offshore team to meet our deadline, and here's why..."
This book is more like the urbandictionary.com than Strunk & White, and some people get that backwards.
I don't think so. In my observation, the primary effect of Design Patterns was to popularize a way of thinking (programming as the stringing-together of predefined constructs) that led a lot of people to write hyper-patterny bad code. This stuff, with its layers of tangled pseudo-abstraction, turned out to be harder to read, work with, and clean up than the plain old bad code they were writing before. But it felt sophisticated to the ones producing it, and they thought they were doing things the "right" way. Of course it's not the authors' fault how others used their book. But as Tim Lister cleverly said (about something else), "if everybody gets it wrong there must be something wrong with it." And I do think there was something misleading about the model the book promoted.
For example, the GoF "patterns" are not at all the same kind of thing, something that the technical format of the book obscured. Some (Decorator) are so simple and ubiquitous that calling them a pattern is silly (like talking about a "parameter" pattern). Others (Iterator) are true formalisms which, as has been pointed out many times, can and should be dealt with at a language level (for the same reason we don't have a "subroutine" pattern). Others (Interpreter) are so general that talking about them as patterns, let alone trying to create a canonical implementation of them, is pointless. Others (Abstract Factory) sound good at first, but are so different every time that they can't be effectively reasoned about (and god, did people make a mess with those). But Design Patterns promoted the idea that this was a collection of similar mechanisms, like tools in a toolbox, or a collection of standardized parts that the programmer would recognize the need for and plug in where appropriate. It sounded good, and came in a pseudo-technical encoding which was the real genius of the book from a sales point of view. But in my observation the whole approach broke down rather quickly in practice.
(Edited in a feeble attempt to make shorter.)
However, I disagree with your central thesis. Programming is the stringing together of predefined constructs. However, like all matters of taste, the hard part is when things are appropriate. Reading the rest of your post as "GoF does not adequately teach when to use redirection, and other techniques of abstraction, leading to sophistry instead of sophistication," I completely agree with what you have to say.
The junior programmers that I know who have read GoF DP have been subject to my endless bashing over the head with the simplicity stick, and so I hope that they use indirection and abstract techniques only as appropriate.
I see what you mean. Yes, but in not the sense I meant. My point is that the predefined constructs in the GoF book are at varying levels of abstraction and granularity, and mostly can't effectively be strung together in the way the book implied. That's my attempt to explain why people mostly created messes when they tried (an empirical observation).
If DP were actually about "indirection and abstract techniques" per se, that would be fine. But it's more than that. It's a cookbook of specific clumps of indirection and abstraction. And I don't think programs can be decomposed into those clumps or composed out of them.
That's mostly what reading Design Patterns is good for. You learn names for things that you'll see over and over again that you can refer to them as when talking to other programmers and you learn to implement them more or less the standard way not because that's novel, but just because it then makes it easier for other people to understand what you've done.
On the other hand, it's easy to read -- like one day, and at that it's definitely worth it.