The moment you set up "throw it over the wall" processes where architects are rewarded for architecture and implementors are blamed for bugs, you are going down the road to something that looks like J2EE no matter where you start.

Thank you for writing this. When I first read the GoF Design Pattern Book I thought "this is the reason, why the code in my project is bloated, unmaintainable and shitty".

Not sure if you know the history, but the authors of the book really only collected the patterns that they had seen around them in Smalltalk and C++ code. They wrote a catalog so we could all refer to the same name instead of using different names for the same concept. They identified the common problems that these patterns tried to solve and they also identified the trade-offs. Oh yes, they identified trade-offs!

Unfortunately, many developers thought that they had to put as many patterns as possible in their code, which was not the intent of the GoF. Ralph Johnson said that they received emails like "I have now used 15 patterns in my project, do you think we should use more?"

Andrzej mentions in his blog post that Java (and C++) lacks dynamic capabilities so this is why sometimes, you need these design patterns to make your code more easily extendable. Other patterns are good even with dynamic languages (observers...).

It depends on the programming language one uses, really. You won't find many references to these patterns on Python's mailing list (or at least I didn't when I was new to the language and used to spend a lot of time there, ~6-7 years ago). Also, when I've tried to learn Lisp or Erlang I didn't find any mentions to such particular patterns (or maybe only in passing), the focus was on something else. And I'm sure there are a lot of other languages outhere who don't bother with patterns.

Adapter is a generic name. Compatibility modules that enable python code to run with python 2 and python 3 are adapters. For example: https://github.com/bartdag/py4j/blob/master/py4j-python/src/...

As for the visitor pattern: http://docs.python.org/library/compiler.html#module-compiler...

They're just not called design patterns. But note that the things in GOF weren't called design patterns in C++ until 1995 either (the GOF book largely predates real use of Java). They were called techniques, or just things you might see in multiple projects.

They're not 'Do this, and you'll have good code', they're just an observation that good code may often use many of these patterns - not because they're forced in there, but because the solution simply maps well to that kind of model.

It's been a while since I read it, but I remember using the book itself as ammo for arguing when not to use particular patterns. They cover trade-offs, and the situations when the pattern may be appropriate or not.

I am pretty convinced that GoF did not expect how popular their book may become. Looking back, it is always easier to judge.

Looking back, with no offense to GoF, what happened can be understood. GoF did a great work for all these "I badly need to sell something new and hot to all these saturated development shops" guys. Read the pattern book once, teach it a hundred times for 2000$ a person. Great stuff.

Now, of course it is due to the single developer to use patterns or not. But the average developer is - well average. Using a pattern is much easier than to understand, when to use and when not to use.

I indeed should have been more precise in my statement: our code got bloated and unmaintainable because there are pattern all over. This is not GoFs fault, it is the fault of all the developers who just read the book and want to apply everything instantly, everywhere. It is also the fault of the community, who did not recognize at once, that pattern should be used only, if they solve a problem that is hard to solve without patterns.

"You've got a singleton class with a single method and no members . . . why don't you make this thing a function?"

"Uh, it wouldn't be a pattern then, would it. Um, would it?"

And the XML. Oh, dear Lord. I have a doctor's slip now stating that I am allergic to XML and that's the reason I'm breaking out in hives, whooping for air and leaving the room.

I sometimes wonder what would have happened to the software industry if the entries in GoF had been written in a different order. Would we see a plague of Visitors and Observers?

[edit] I didn't mean to sound so negative about GoF. Know the patterns so you know when to use them, and when to avoid them. You can't debate these decisions when you're ignorant of design principals and history.

I agree that it's not java the language (java's boring, but not unusable), it's the java culture from the last decade that drives people away.

This lack of abstraction mechanisms was by design; it was supposed to be simpler than C++, and it is. Unfortunately, it came from an era where people still thought OO was the uberparadigm and it met every need in it simplest form. I think I can safely close the book on that as being false; at the very least you need OO with borrowed features from older-generation functional languages like closures and first-class functions, like Python or Ruby.

I've really only been viewing this from the deployment side for quite a while, but when I'm trying to help you troubleshoot your relatively simple webapp, and I have thousands of lines of stacktraces that bubbled up through a half dozen frameworks, it's hard to blame just the language.

Have you tried Java EE6 (the app-servers that support Java EE6 or just the subset of Java EE6 have improved significantly as well via OSGi).

I'm worried that people will think I'm a broken record on the topic of java, but this discussion is coming up a lot these days, and I think a lot of people are doing a mental re-evaluation of Java. One thing that comes up a lot is that Java itself isn't terrible, but J2EE (as well as Spring and other frameworks many developers consider over-complicated) has made the experience of being a java developer (especially someone new to the environment) unpleasant.

While some people mention frameworks like Play, I'm interested in what people think of going back to the Servlet + Libraries approach that was common in 2004, just before Struts/Spring hit the scene. It's verbose, and I'm not saying we should just go back to the way things were, but I think developers might want to embrace the low levelness and verboseness of Java.

My take on it is - if I'm happy to work within the conventions of a framework, then I'd probably be happy with Rails or Django. If I want to write Java, then I probably want a very detailed level of control over my code base. In this case, it might make sense to start with the bare-bones (servlets and jdbc), and grow into what I think I need through libraries rather than an over-arching framework like Spring.

In general, I think I would want to use MVC and DI, but I'd like these things to be as unobtrusive as possible, and easy to add or remove, like libraries rather than something that dominates my code from the very beginning...

Honestly, my thoughts aren't completely formed on this yet... I just find it interesting how so many people on HN are starting to discuss this now. Often, there's a reason that developers start to focus on a particular issue at the same time.

If I had to name the single biggest class of make-work in my life in the last 10 years, that would be it: maintaining legacy Struts crap.

The creator of struts should be in Gitmo for a year or two, perhaps with access to a functional programming environment a few hours a week if he behaves himself :-)

Java: providing a job with benefits. Like the episode of "The Simpsons" where Homer has to go back to the nuclear power plant to work, to pay for his daughter -- "Do it for her."