I agree with you for the most part - what you're describing is rampant abuse by cargo-code programmers that don't know better.
This doesn't mean GoF design patterns are specifically wrong. It's just that they are misused and applied in places they don't belong. When done properly, they should emerge organically as you code without you even realising it (That is to say good design patterns are emergent phenomena in good code, not the other way around).
It also doesn't help that the entire software industry is fixated on single-inheritance OO languages, which tend to encourage ridiculously bad designs.
> It's cheaper and more reliable to chop your product up and write each chunk in whatever separately with no official architectural pattern usage system-wide.
This nails good software design on the head. Don't write large software, write small independent reusable components and combine them together.
This is what dependency injection solves well - When done properly. (If it involves XML or config files it's not done properly).
I think, as Peter Norvig once pointed out, that design patterns are a symptom of an anemic language design. They cost us time and complexity for their benefits. Java wouldn't need half the patterns typically employed to work around the limitation that there are no first-class functions.
Eich himself admitted to avoiding adding classes to Javascript in his interview with Peter Siebel for Coders at Work:
SIEBEL: So you wanted to be like Java, but not too much.
EICH: Not too much. If I put classes in, I'd be in big trouble. Not that I really had time to, but that would've been a no-no.
It's a really good interview and I recommend the book. It seems like Javascript was supposed to be an Algol-syntax over a non-pure Scheme inspired core... but due to constraints was thrown together like most code is when there's a looming deadline.
My point was mostly a sarcastic insight into what it's like for these companies but you're right: there are valid uses and the fundamentals really are spot on. In fact I'm probably #1 fan of Martin Fowler who has spent many years researching, collating and understanding these patterns so they can be communicated to others effectively.
The problem is that it takes literally a decade to actually understand how to use these properly in one specific language (and possibly mostly effectively in another). Until you reach this point, your toolbox isn't filled with the sharpest tools as your team isn't going to be filled with 10 year+ senior staff across the board.
At that point, it goes to shit, every time. These patterns and techniques aren't just tools - they require experience right from the get go and a lot of people just aren't capable of nailing it even in a decade.
This doesn't mean GoF design patterns are specifically wrong. It's just that they are misused and applied in places they don't belong. When done properly, they should emerge organically as you code without you even realising it (That is to say good design patterns are emergent phenomena in good code, not the other way around).
It also doesn't help that the entire software industry is fixated on single-inheritance OO languages, which tend to encourage ridiculously bad designs.
> It's cheaper and more reliable to chop your product up and write each chunk in whatever separately with no official architectural pattern usage system-wide.
This nails good software design on the head. Don't write large software, write small independent reusable components and combine them together.
This is what dependency injection solves well - When done properly. (If it involves XML or config files it's not done properly).