Design patterns criticism sources

Most of the criticisms of design patterns that I have come across relate to a distaste for the structuring and labeling of what they consider to be just good object-oriented practices. Most patterns boil down to programming to interfaces, and other SOLID principles. The feeling is that when we teach patterns we cause developers, especially junior developers to try to cram all problems into the set of patterns that they have learned, which can create more obtuse and cumbersome problems than if they had taken a more 'straightforward' approach.

I tend to agree with the sentiment that once you begin to learn patterns you tend to overuse them, however, typically you very quickly move out of that stage, and into a much more productive and professional software career afterward.

As a bonus, here is a bit of mild criticism from Jeff Atwood and some critical insights from Mark Dominus

Alan Kay himself is very critical about patterns because he doesn't believe software should be so vaunted. Here's a 2012 Dr. Dobbs interview with Kay.

"The most disastrous thing about programming — to pick one of the 10 most disastrous things about programming — there's a very popular movement based on pattern languages. When Christopher Alexander first did that in architecture, he was looking at 2,000 years of ways that humans have made themselves comfortable. So there was actually something to it, because he was dealing with a genome that hasn't changed that much. I think he got a few hundred valuable patterns out of it. But the bug in trying to do that in computing is the assumption that we know anything at all about programming. So extracting patterns from today's programming practices ennobles them in a way they don't deserve. It actually gives them more cachet."

One big criticism against design patterns is about how "generic" some design patterns really are. For instance, the Strategy Pattern implementation seems to be more relevant (and complex) in languages that lack lambdas/first-class functions (as we may notice here).

But I think this argument ignores the simple fact that design patterns do exist: we can perceive patterns in code, any code. Once we notice them, we can start using them as a clear, language-agnostic way of describing and understanding software architecture. So the fact that some design patterns have easier implementations in (or are directly supported by) certain programming languages is something to be aware of, of course; but using that as an argument against design patterns is absurd, in my opinion.

Of course, I do also agree that many enterprise design patterns would not fit in a pure functional language. But I also believe the functional world has its own set of design patterns too (like the Monad).

Finally, one interesting discussion on design patterns (even if a bit chaotic) can be found on this Hacker News thread. This post from user @thom presents a similar opinion to mine:

It's important to note the difference between the technical mechanism and the motivation for a design. Yes, lots of languages can pass functions around so perhaps you think the Strategy pattern doesn't apply to you. And yet I see huge numbers of APIs that still take enormous option maps and don't offer configuration with some sort of callback, however simple the host language might make it. Patterns capture a design choice as much as a technical implementation.