I like Bruce Eckel's take on things. His latest article is titled: "Where is Thinking in Java, 4th Edition?". I'd take that back and ask where it ever was, but I digress. Here's the lead quote that jumps out at you:

Another way to look at it is to say that J2SE5 has made me realize how complex Java has become. It's been sneaking along with the various releases, but J2SE5 (clearly driven by the features in C# 2.0) has leapt forward far enough that you suddenly wake up and say "hey, this isn't a 'simple' language anymore!" (Many will argue that it never was).

That's because of the way that Java and C# add features. Both started from highly constrained languages, where the thinking was "let's protect the developer from himself". The last few years have been a slow agglomeration of new language features, and each one has had to be layered on top of the original "don't allow power" mindset. The inevitable result? Complete baroqueness.

Consider Smalltalk, in contrast. It was designed to enable developers, rather than to constrain them. At the language level, Cincom Smalltalk has only had one major change in the last twenty years - the addition of namespaces. That addition didn't massively change things from the end user's standpoint, either - if you kep coding as you always did, leaving everything in the "Smalltalk" namespace, you could mostly ignore namespaces. I use namespaces to segregate code, and I've only had to spend time thinking about the issue for a handful of my packages.

Back to Bruce's article - he gets to generics, where he throws his hands up in despair:

The problem is that it's not quite either of these things. If you throw up your hands and say "OK, better containers is what it's all about, now I don't have to worry about upcasting and downcasting," you soon discover situations where generics can allow you to write more effective code which falls outside that description. But as soon as you decide that it's a true generic mechanism, you run into the wall of erasure -- you don't really know what type the generic code is working with. To partially compensate for this, you must introduce bounds, which leads to covariance and contravariance. By comparison, C++ templates are vastly simpler and more powerful; indeed, the only real problem with C++ templates is the horrible error messages that compilers have traditionally produced (The next version of C++ intends to solve this problem quite effectively). So you need to understand why Java generics don't have the power and simplicity of C++ templates (answer: migration compatibility -- using old libraries in J2SE5).

It's always a bad sign when you start thinking that C++ was simpler and more powerful. Again, Smalltalk walks clear around this problem - by not having manifest typing, the developer is simply liberated from the problem. You end up considering how and when to use polymorphism instead of looking crap up in chapter X of your dog-eared rulebook. Bruce went into detail on this last June, in his "Generics Considered Harmful" post.

The basic issue - Java started from a complex base - ironically so, since the idea was to simplify from C++. By starting with the notion that constraining programmers was critical, the language was permanently hamstrung - and each new feature that gets layered on makes it worse. C# started in the same place, only with a lot of the fashionable baroqueness layered on from the get-go.