That statement is almost the opposite of true. The GoF patterns were invented to paper over the inadequacies of Java and C++ and make them behave more like languages like Ruby and Python.
I think Norvig's presentation should be required reading in order to obtain your Ruby or Python programming license:
That is not entirely true. GoF patterns have tons of examples in Smalltalk, which is as dynamic as Ruby/Python.
But they are more verbose and awkward to use in statically type languages, languages without first class functions (unlike Smalltalk, Ruby and Python), and methods like doesNotUnderstand, method_missing or __getattr__.
And languages with mixins/metaprogramming support can do pretty much all patterns in a much better way (this is easy to see on the paper[1] where Gregor Kiczales implements the patterns in AspectJ and see how much simpler they become when you have mixins).
The biggest problem with patterns is that people start with them, instead of refactoring to them when needed [2], which leads to a lot of over engineering (which is a form of premature optimization, and we all know what Knuth said about that).
I remember how we all waited with bated breath for Design Patterns to come out. It was a bit of a disappointment, I recall. Seemed kind of complicated. So now for some of our patterns we need four C++ files per object? Heck with that.
I would disagree that there are tons of Smalltalk examples there. There are in fact a few examples, and they actually don't weigh very much, because they are pretty small, and you don't really need the whole Design Patterns concept if you are a Smalltalk dude. I have a friend who first picked up the book after programming for 17 years in Smalltalk. He put it down after scanning through the first few chapters because it was very self-evident to him.
For young up-and-coming programmers, I recommend setting aside Design Patterns and reading everything you can find written by Peter Norvig. Start with his design patterns essay. The short version of which is that if you need design patterns, (in the sense of the book) then there is something lacking in your language. They are an unnecessarily.
I would never recommend Uncle Bob to anyone looking to improve programmming chops. Read Norvig instead. Uncle Bob came down on the wrong side of TDD and the fellow who failed to TDD his way into a sudoko solution. Peter Norvig comes up with a different notation, not a methodology, not a design pattern, and produced a very elegant solution.
So to improve your programming skills, avoid Uncle Bob, read Norvig, go easy on the methodology.
> dynamic dispatch (thin of doesNotUnderstand, method_missing and __getattr__)
Dynamic Dispatch has a very well-defined meaning. It means dispatching based on the runtime type of a variable rather than the declared, static type. The three methods you mention just happen to exist in languages that feature only dynamic dispatch.
I'm not sure if there's a formal term for the methods you refer to, but they aren't "dynamic dispatch".
Actually there is. This is a reification of the call stack (so it is a reflection trait of the language) called method lookup alteration and interception[1]
But thanks for pointing it out. I've edited the original comment to avoid confusion.
To rephrase the quote: Design patterns can be good in the appropriate situations, but Java's heavy use of them has soured people on them altogether.
They're often used ad absurdum in Java, to the extent where even in situations you don't need the complex functionality they support, you're stuck using them (often incorrectly because you don't need them) and they become a burden instead of useful.
In addition to your point, when writing in a language like Java, the overhead of writing code makes doing things the right way (in this case, using a design pattern) harder.
Steve's example of the Strategy pattern is a good example of this. Contrast using this pattern in C (function pointers), in Java (inner anonymous classes conforming to an interface) and in Ruby (a block).
Design Patterns are names given to ways of doing things, so that programmers can talk about the same things.
Any time you forget that, or start using phrases like 'Anti-Pattern', you lose (unless you're an expensive consultant, then you're about to get paid!). This appears to be the current forefront of Java development methodology (based purely on what I've read on HN).
I think Norvig's presentation should be required reading in order to obtain your Ruby or Python programming license:
http://norvig.com/design-patterns/
Think of all the countless lives that could be saved.