I forget who said it, but I ascribe to the notion that most design patterns exist to work around insufficiencies in languages or ecosystems. To that end, a lot of them totally still exist--they've just been reduced in difficulty and ceremony, as you mention. The command pattern, for example, is literally just a closure.

You're probably thinking of when Peter Norvig said: "Design patterns are bug reports against your programming language."

> I'm sure the Gang would concur.

I'm pretty sure this is the case. I think that the ideas are great in producing a vocabulary for classes of structures within software architecture the way people creating a car can talk about gears, rotors, pistons, gaskets.

Whether or not you have the right rotor/gears/gasket/piston is up to the specific case. And sure some of those things may become like carburetors, and may become largely obsolete. But there is definitely a value in having a consistent vocabulary for things like "That box that controls the air-fuel-ratio mixture before it goes into the cylinder."

Same problem a lot of good ideas have (like unit testing or agile), an idea meant to be evolved and applied thoughtfully instead becomes ossified instantly and applied mindlessly, with many mistakes, and zealously.

The concept of design patterns is highly useful. The particular patterns in one book would always be of limited usefulness. Often times devs are more eager to prove their smarts than to get a job done well.

> ...an idea meant to be evolved and applied thoughtfully instead becomes ossified instantly and applied mindlessly, with many mistakes, and zealously.

That's such a good quote, I just may copy + paste it mindlessly into my next presentation and assert it with zeal. (With credit of course)