There seems to be waves of online articles discussing that Java has reached its end, and in its wake are the fresh, energetic youths of dynamic languages like Python and Ruby… yeah, when I was a kid, we used to call them scripting languages, but everyone nowadays have illusions of grandeur.

But I come not to praise or to bury Java, as I completely agree with the idea of using the best tool for the job. But scripting languages, while very useful, have a sinister side. It lulls you into its easy embrace of “get something done quick” and before you know it, you’re left supporting a mountain of cards.

I was recently helping out a company get their website up and running, and when I logged onto the machine, I was aghast. Here was a cgi-bin full of CGIs written in Perl using every bad technique I could think of… from hundreds of hard-coded path references in each file to embedded passwords to other machines. It was a mess.

Seldom do we make the right design decisions the first time, we don’t always know what we want, or the best way to build it, and so for my money, it isn’t how easy it is to initially write it, but how easy it is to refactor it.

The other day, as I was analyzing a bit of code that needed a better API for its client, it became obvious that a class with a gargantuan list of methods shouldn’t be passed around. We should, instead, use a simpler interface to the class… but this class was referenced everywhere.

But this is where a strongly typed, compiled language shines when it holds hands with a good IDE. In Eclipse, I simply right-clicked on the class, and under the Refactor menu, I chose, Extract Interface. I then clicked on the methods that should be exposed, and then clicked the magical button that would refactor every other reference to use the interface instead.

Sure, you may have to type more in Java than in a shell script, but I don’t have to. My IDE, with its “context assist”, and its “templates”, and its automatic code generation does most of the work. This is why projects such as Groovy look interesting for about 3 minutes. A simplified scripting language in Java that ends up getting compiled into Java, really doesn’t help that much. The advantage that it saves one from typing “public void main()” is moot since I haven’t typed a class wrapper since I first installed Eclipse.

I’ll be the first to admit that EJB’s were a huge mistake, but hasn’t Spring redeemed us? Well, it will as long as they keep it from getting bloated… but that’s another issue.

Language philosophy aside, I’ve seen terrible programs written in every language, and I would suggest every aspiring developer to learn a collection of good design and coding skills, and a half-dozen languages, because a language is another tool in your box.

An old friend of mine, Levi, wrote me the following rebuttal:

Although I agree with a number of the points you made here, I have a different perspective on how it all fits together.

Before the term ‘scripting language’ was brought into fashion by tcl and perl, there was already a long history of languages that brought dynamic typing, rapid development cycles, and exploratory programming to the table. Lisp and Smalltalk are the old guard examples of the ‘dynamic language’ camp, and both are systems/applications programming languages with long histories of commercial success. Just because Ousterhout painted tcl and perl with the ‘glue language’ brush doesn’t mean all dynamically-typed languages are scripting languages, though perl, python and ruby certainly do have features that make them useful in that arena.

Refactoring, in the software development sense, was coined by the folks who invented Extreme Programming. The Extreme Programming people were all Smalltalk programmers while they were developing the practices that are now embraced (in whole or part) by most of the object oriented programming community. This isn’t to say that Smalltalk is necessarily superior to Java, just that the lack of static typing was not a detriment to good software design! In fact, the refactoring support in Eclipse was not invented there, but adapted from the Smalltalk browser. The extra type information in Java can give Eclipse extra hints, but it’s certainly not necessary for refactoring support.

Guy Steele, who was hired by Sun to help with the Java effort, once remarked that the goal of Java was not to attract Lisp programmers, but to drag the C++ programmers halfway to Lisp. I think you could substitute Smalltalk in there for Lisp and get pretty much the same effect. As such, I don’t think of Java as an end, but as a means of moving the programming community by baby steps from the world of C-style programming to the world of Lisp/Smalltalk-style programming.

I believe that, as a halfway language, the writing is on the wall for Java. It is still a fine and useful programming language, especially with the help of Eclipse (which now has Ward Cunnignham, Smalltalk programmer and XP/Patterns guru, behind it), but its time in the spotlight is passing. I don’t know that Python and Ruby will necessarily be the next big thing, but certainly Java is not the last word in programming languages.