Death of Java?
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
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
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
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
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
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.
Tell others about this article: