I'd rather just see the idea of Proper Noun Design Patterns die, in my experience they've done more harm than good by not emphasizing their tradeoffs. My struggles with over-eager developers turning everything into a smorgasbord of over-abstract design patterns outweighs any benefits I ever got from them (there's a similar tendency with some functional programming enthusiasts). I think we're better off tucking these into language documentation and calling them "idioms", to keep the zealots and dogmatists from turning them into thought-terminating cliches.
> Meanwhile vast amounts of memory and CPU power mean flyweights and object pools aren't so useful and immutability is now a valid design goal.
I don't agree, they are still widely used in most languages, but are often hidden behind abstractions so that developers don't need to know about them.
This is a problem with bad developers - the general idea of patterns makes a ton of sense because pattern recognition is important and it makes it easier to reason about the properties of various parts of code.
Blaming bad developers and hoping for them to try harder isn't going to make anything better.
I totally agree that patterns are important and useful, I just think that the way they're presented and over-emphasized is net-harmful, and that by changing that we can make the situation better.
>>Blaming bad developers and hoping for them to try harder isn't going to make anything better.
Well, but it does, doesn't it?
I mean, the first step to solve a problem is to identify it. Clearly, the problem with design patterns is that clueless developers have no idea what they are talking about, thus they mount incomprehensible complains that make no sense if you'd understood the basics.
Developing software is a complex endeavor that is much more than declare variables and nest control statements. There is way more to developing software than what is covered by a "intro to language X" or "learn framework Y" blog post.
If a programming language gives you brick and mortar, you start to talk about retaining walls and windows and stairs. If a programming language gives you gears and screws and bearings and springs, you start to talk about pumps and differentials and dampers.
So what's hard to understand in needing design patterns to talk about components and solutions to common problems?
> Meanwhile vast amounts of memory and CPU power mean flyweights and object pools aren't so useful and immutability is now a valid design goal.
I don't agree, they are still widely used in most languages, but are often hidden behind abstractions so that developers don't need to know about them.