To be relevant to the thread, those systems must be insanely complex, unreliable and unmaintainable, because the Java developers who made them has these habits that Java developers apparently have.

To the extent Java correlates with bad software, IMHO the causation is more likely to be that the environments (in the vein of clueless corporate management, waterfall, http://www.halfarsedagilemanifesto.org/) are more likely to pick Java for their development.

Well, maybe, but the cultural argument is also applicable. With my first Java app I did this kind of stuff because the examples of Java I found implied that this was a good thing to do. I didn't have a lot of experience in this area, so I thought, "these folks have been around the block, experienced the pain, and now have words for the wise." So I did it too.

I wonder if I will actually ever use one of those factories again in that app.

One of the things that annoys me in Java books is that every meaningful example is a couple pages long, most of it giving context to a function or method. The process of writing a meaningful may be so painful and risky Java programmers defend themselves by starting with code so generic they believe it won't need rewriting in the future.

> because the Java developers who made them has these habits that Java developers apparently have.

That's the point. Java, it seems, make it tempting to "overarchitect" applications into excessively generic and modular beasts early in their lives when a much simpler implementation would be perfectly adequate and much simpler to extend and maintain.

You can do that in any language. Java's ubiquitousness means that there's a lot more bad code, especially when you look at some of the places it's become ubiquitous.

But you know what? Once we've established that you can write bad code in any language.. I'd prefer to deal with bad code in Java than almost any other language I can think of (and I've seen a fair bit). Maybe Python wins out, but I'd rather debug bad Java code than bad C++ or bad Ruby for sure.

I did not have to deal with bad Haskell, yet. But I wonder, how it would turn out. The type-system can give you some pretty strong guarantees (if you abstain from using back-doors), and thus make interfaces much less leaky. I.e. if a function has the type String -> Int, you know that it takes a String and gives an Int, and doesn't have any strange side-effects, like setting some random variable or sending away your credit-card data.

Bad Haskell usually involves poor type abstractions, eg. instead of defining new data types for inputs that are logically distinct but physically identical, you just re-use existing types and add new constructors. Or you end up using tuples for everything. Or (horror!) you encode a bunch of things as strings instead of using the type system at all.

The nice thing about Haskell is that it's really, really hard to write things that accidentally ignore purity, which eliminates a whole class of errors and bad designs. The type system only helps you if you let it, though.

Yes, that's sounds plausible.

I've looked at a friend's Haskell program for Huffman encoding, that used raw recursion in a undisciplined way instead of abstracting the control flow out into, say, filters, folds and maps. That was the closed I ever got to ugly Haskell.

What programming language is that not the case for?

Messes, perhaps, may be more frequent in PHP/ASP applications, but insanely convoluted and overarchitected solutions with unrequired levels of indirection and never used configuration XML files that have to be generated by an IDE are much more frequent in the Java/C# camp than, say, in the Python/Ruby/Perl/Smalltalk camp.

c.f. Spring, EJB, JBoss, anything J2EE, etc.