This explains thoroughly what is wrong with design patterns ala GOF. It's not that particular frequent patterns in particular languages or enumerating them in academic fashion is wrong. It becomes wrong when sophistry of these band-aids to language flaws are raised as somehow being really important, when actually they are just reactions to accidental complexity. It often creates unnecessary complexity to description of systems and cargocult overengineering.
I would claim that it's much more beneficial for budging engineers to program something they have not programmed before (like a space invaders clone or a scheme interpreter) than to remember each GOF pattern.
And, since these band-aids are unnecessary in several languages, it would be much more fruitful to learn one of these languages rather than memorize some band-aid.
The reason the patterns are common is that they are pretty much obvious after you understand the low-level language and you are familiar with some higher level language.
It's nice to be able to give things names, but, being able to name a bird does not mean you know anything about it's important characteristics. Or, to misquote Feynman, "GOF design patterns are pretty much as important to software engineering as ornithology is to birds".
Also, if you read Christopher Alexander's work, I would claim that GOF patterns are not patterns in the sense Alexander uses.
I've seen quite a bit of damage done by GOF patterns. Simple code bases become more complex due to an implementation of some GOF pattern because that's "the modern way to do it by the book".
I would claim that it's important to first figure out a most simple way to do something, and if it fits into some GOF category then fine, you can identify it and move on.
I wouldn't say "what is wrong". I mean, the patterns stand on their own merit: they provide a recipes for solving commonly recurring program design problems in Java, C++ and their ilk. "What is wrong" is making a religion out of them: elevating these patterns to an overly important status, as if they are some important generalities in software engineering, if not in fact computer science or even mathematics.
While that paper is specifically addressed to "Dynamic Languages", I suspect you'd find similar things with modern static functional languages with more robust type systems (Haskell, particularly.)
I actually found that comparison to be a great example of why design patterns are useful. By naming the pattern, Norvig was able to instantly list 16 ways in which dynamic languages solve real-world problems.
This explains thoroughly what is wrong with design patterns ala GOF. It's not that particular frequent patterns in particular languages or enumerating them in academic fashion is wrong. It becomes wrong when sophistry of these band-aids to language flaws are raised as somehow being really important, when actually they are just reactions to accidental complexity. It often creates unnecessary complexity to description of systems and cargocult overengineering.
I would claim that it's much more beneficial for budging engineers to program something they have not programmed before (like a space invaders clone or a scheme interpreter) than to remember each GOF pattern.
And, since these band-aids are unnecessary in several languages, it would be much more fruitful to learn one of these languages rather than memorize some band-aid.
The reason the patterns are common is that they are pretty much obvious after you understand the low-level language and you are familiar with some higher level language.
It's nice to be able to give things names, but, being able to name a bird does not mean you know anything about it's important characteristics. Or, to misquote Feynman, "GOF design patterns are pretty much as important to software engineering as ornithology is to birds".
Also, if you read Christopher Alexander's work, I would claim that GOF patterns are not patterns in the sense Alexander uses.
I've seen quite a bit of damage done by GOF patterns. Simple code bases become more complex due to an implementation of some GOF pattern because that's "the modern way to do it by the book".
I would claim that it's important to first figure out a most simple way to do something, and if it fits into some GOF category then fine, you can identify it and move on.