I said here (and someone else said that too) that "Java is the new cobol".
When saying so, I mentioned that En3pY hates Java, here it is another post by him written after I forwarded him this Joel Article (which I read from Scoble, in turn).
All in all, in this case, I tend to partially agree on some points but slightly disagree on others with Joel.
In fact, while I do acknowledge the need of "hardcore" developers to fix and build lower level things and mantain current code (and know WHAT they are doing), there are also many cases where coding in a high level language which abstracts complexity IS actually more efficient and cost effective, not having to reinvent the wheel every time.
So there are a lot of useful and nice programs written by people who DO KNOW what happens under the hood (as good in C as in Assembler), that for simplicity and flexibility run in sandboxes, high level languages, even interpreted ones! An example is Dave Aitel's CANVAS, written in Python. But that's just an example.
But I do agree with En3pY that I don't like Java myself, and I consider it being too "heavy", in general.
Solution on my side, tough, is that you don't need C or assembler to get cleaner, smaller, more efficient code, you just need better languages. An example of this is a situation I have been involved in some time ago: in that case a colleague (that works with a very large customer who has a very large exchange deployment) needed to do some performance testing of this Exchange system. He had done the testing from some Windows IMAP clients, but the customer also wanted to see the same performance values measured from a Linux box accessing the same exchange via the very same IMAP protocol.
So I wrote a nice and sweet Ruby script – and at the same time another colleague developer a similar application (in Java).
Result: 45 kilobytes of .JAR to do the same things I did in 20 lines of Ruby (20 lines – including comments!).