What does a high-level language accomplish? It frees a program from much of its accidental complexity. An abstract program consists of conceptual constructs: operations, datatypes, sequences, and communication. The concrete machine program is concerned with bits, registers, conditions, branches, channels, disks, and such. To the extent that the high-level language embodies the constructs wanted in the abstract program and avoids all lower ones, it eliminates a whole level of complexity that was never inherent in the program at all.
- No Silver Bullet - Fred Brooks
By now everyone out there has probably read, or seen snippets of Stevey's post, Code's Worst Enemy. It's a great post, and I recommend reading it thoroughly if you haven't already.
Of course, there's a lot of people - in the Java community especially - that are probably looking at it as a "Java Sucks" rant, which it certainly seems to be in some ways. For the record, I do think he's a bit harsh toward the Java development community out there: Most Java developers - myself included - know that Java (as well as it's accompanying frameworks and tools) can make a software system unnecessarily complex. The problem is we're not much in a position to do anything about it. I'd love to be using a language like Ruby or Python that mitigate this. Hell, I'd love to be able to use Lisp on a project, but I'd be flogged for trying to in my current position
It's not all the community's fault, ya know.
But, Java ranting aside, what Steve's (rather long) post is really about is dealing with complexity - more specifically, accidental complexity. If you don't know what accidental complexity is, go follow that link on the last sentence and come back. Or, better yet, go read The Mythical Man-Month. Either way you'll be a better developer if you know what the heck it is. Trust me.
There's a good example of the accidental complexity issue in this post on Raganwald.
The Java language does have it's fair share of accidental complexity. Nevertheless, the industry made the big transition to Java because it removed some accidental complexities that other languages, such as C++, had. A good example is memory management: Java removed this problem from the programmer's mind (not completely, but enough that we don't have to actively think about it) so that he or she can focus on solving the core problems at hand.
What we're seeing now is that, as Java gets thrown at more and more complex problems, the flaws in the language are becoming more apparent: The accidental complexity of the language itself is getting mixed up in the essential complexity of the systems being developed. There are also new problems that have arisen as a result of the Internet and Web development that weren't known (or at least, not readily addressed) at the time of Java's inception. The result is that these problems are dealt with via complicated frameworks for Java (which add to the accidental complexity of a system, causing code base "bloat"), but in much simpler ways in other languages like Ruby.
This is also a reason why we see discussions about new languages constructs in Java like closures: People are trying to find ways to solve these accidental complexity issues in the language, without having to retool entire code bases in a new language.
But ultimately, we're looking at a situation now where developers are looking for better ways to solve the really complex problems out there and aren't finding a viable option. The industry is ripe for a new language to step in a take over the reins from Java, removing another bit of accidental complexity from our lives and allowing us to focus our minds just a little bit more on the problems we're trying to solve.
The sooner, the better.
update 01/03/08: Little slow noticing (took a long holiday break), but I got a link from Raganwald. That's usually a sign that you've written something intelligent (or at least interesting). I didn't think I had it in me :-).
Belated thanks to Mr. Braithewaite for the link.