Java: "Done" like the Patriots, or "Done" like the Dolphins?

---

English is a wonderful language, isn't it? I'm no linguist, but from what little study
I've made of other languages (French and German, so far), English seems to have this
huge propensity, more so than the other languages, to put multiple meanings behind
the same word. Consider, for example, the word "done": it means "completed", as in
"Are you finished with your homework? Yes, Dad, I'm done.", or it can mean "wiped
out, exhausted, God-just-take-me-now-please", as in "Good God, another open-source
Web framework? That's it, I give up. I'm done. Code the damn thing in assembler for
all I care."

So is Java "done" like the Patriots, a job well accomplished, or "done" like the Dolphins,
the less said, the better?

(For those of you who are not American football fans, the New England Patriots have
gone completely undefeated this season, a mark only set once before in the game's
history, and the Miami Dolphins almost went completely unvictorious this season, a
mark never accomplished. [Update: Hamlet D'Arcy points out, "Actually,
a winless season has been accomplished before. Tampa Bay started their first two seasons
winless with an overall 0-26 record before finally winning its first game in 1977."
Thanks, Hamlet; my fact-checking on that one was lax, as I was trusting the commentary
by a sportscaster during the Dolphins-Ravens game, and apparently his fact-checking
was a tad lax, as well. :-)] The playoffs are still going on, but the Patriots
really don't look beatable by any of the teams remaining. Meanwhile, the Dolphins
managed to eke one out just before the season ended, posting a final record of 1-15,
something reserved usually for new teams in the league, not a team with historical
greatness behind them. And that's it for Sports, back to you in the studio, Tom.)

Bruce Eckel seems
to suggest that Java is somewhere more towards Miami than New England, and that
generics were the major culprit. (He also intimates that his criticism of generics
has swayed Josh and Neal's opinions to now being critical of generics, something I
highly doubt, personally. More on that later.) Now, I'll be the first to admit that
I think generics in Java suck, and I've said this before, but the fact remains, no
one feature can sink a language. Consider multiple inheritance in C++, something that
Stroustrup himself admits (in Design and Evolution of C++) he did before
templates or exceptions because he wanted to know how he could do it. Lots of people
argued for years (decades, even) over MI and its inclusion in the language, and in
the end....

... in the end MI turns out to be a useful feature of the language, but not the way anybody figured
they would be. Ditto for templates, by the way. After looking at the Boost libraries,
even just the basic examples using them, I feel like I'm looking at Sanskrit or something.
As Scott Meyers put it once, "We're a long way from Stack-of-T here, folks."

And that is my principal complaint about generics: the fact that they aren't fully
reified down into the JVM means that we lost 90% of the power of generics, and more
importantly, we lost all of the emergent behavior and functionality that came out
of C++ templates. Nothing new could come out of Java generics, because they
were designed to do exactly what they were designed to do: give us type-safe collections.
Whee. We're cooking with gas now, folks. Next thing you know, they'll give us printf()
back, too.

(Oh, wait, they did that, too.)

Fact is, there's a lot of things that could be done to Java as a language to make
it more attractive, but doing so risks that core element that Sun refuses to surrender,
that of backwards compatibility. This was evident as far back as JavaPolis 2006, when
I interviewed Neal and Josh on the subject; when asked, point-blank, why generics
didn't "go all the way down", a la .NET generics do, they both basically said, "that
would break backwards compatibility, and that was a core concern from the start".
(I disagreed with them, off-camera, mind you, particularly on the grounds that the
Collections library, the major source of concern around backwards compatibility, could
have been ported over, but then Neal pointed out to me that it wasn't just the library
itself but all the places it was used, particularly all those libraries outside of
Sun, that was at stake. Perhaps, but I still believe that a happier middle ground
could have been eked out.) That is still the message today, from what I can see of
Neal's and Josh's public statements.

And the fact is, so far as it goes, Java generics are (ugh) useful. Useful solely
as a Java compiler trick, perhaps, and far more verbose than we'd prefer, but useful
nonetheless. Using them is about as exciting as using a new hammer, but they can at
least get the job done.

There, I've made the obligatory "generics don't completely suck" disclaimer,
and I'll be the first one to tell you, I just live with the warnings when I write
Java code. Possibly that's because I don't worry too much about type-safe collections
in my code, but I know lots of other programmers (particularly those on teams where
the team composition isn't perhaps as strong as they'd like it to be) who do, and
thus take the extra time to write their code to be generics-friendly and thus warning-free.

The mere fact that we have to work at it to create code that is "generics-friendly"
is part of the problem here. For all those who came from C++ years ago, you'll know
what I mean when I say that "Java generics are the new C++ const": Writing const-correct
code was always a Good Thing To Do, it's just that it was also just such a Damn Hard
Thing To Do. Which meant that nobody did it.

Languages should enable you to fall into the pit of success. That's the heart of the
Principle of Least Surprise, even if it's not always said that way. (I'm not sure
that C# 3 does this, time will tell. I'm reasonably certain that Ruby doesn't, despite
the repeated insistence of Ruby advocates, many of whom I deeply respect. I'm nervous
that Scala and F# will fall into this same trap, owing to their unusual syntax in
places. It will be fun to see how ActionScript 3 turns out.)

Here's a thought: Let's leave Java where it is, and just start creating new JVM languages
that cater to specific needs. You can call them Java, too, if you like. Or something
else, like Scala or Clojure or Groovy or JRuby or CJ or whatever suits your fancy.
Since everybody compiles down to JVM bytecode, it's all really academic--they're all Java,
in some fundamental way. Which means that Java can thus rest easy, knowing that it
fought the good fight, and that others equally capable are carrying on the tradition
of JVM programming.

Eckel makes a good point:

Arguably one of the best features of C is that it hasn't changed at all for decades.

... which completely ignores some of the changes that were proposed and accepted for
the C99 standard, but we'll leave that alone for now. The point is, the core C language
now is the same core C language that I learned back in my high school days, and most,
if not all, C code from even that far back will still compile under today's compilers.
(Granted, there's likely to be a ton of warnings if you're using old "K-and-R" C,
but the code will still compile.)

What about evolution, though? Don't languages need to evolve in order to stay relevant?

Consider the C case: C++ came along, made a whole bunch of changes to the language,
but went zooming off in its own direction, to the point where a standards-compliant
C++ compiler won't compile even relatively recent C code.

And how many people have complained about that?

By the way, if you're a C/C++ programmer and you haven't looked at D,
you're about to get leaped on the evolutionary ladder again. Just an FYI.

As a matter of fact, if you're a Java or .NET programmer, you'd be well-advised to
take a look at D, too. It's one of the more interesting native-compilation languages
I've seen in a while, and yet arguably it's just what a C++ compiler author would
come up with after studying Java and C# for a while (which, as far as I can tell,
is exactly what happened). And because D can essentially mimic C bindings for dynamic
libraries, it means that a Java guy can now write a JNI DLL in a garbage-collected
language that (mostly) does away with pointer arithmetic for most of its work... just
as Java did.

Heck, I'd love to see a D-for-the-JVM variant. And D-for-the-CLR, while we're at it.
Just for fun.

Let's do this: somebody take the old, pre-Java5 javac source, and release it as "JWH"
(short for Java Work Horse), and maintain it as a separate branch of the Java compiler.
Then we can hack on the new Java5 language for years, maybe call it "JWNFF" (short
for Java With New-Fangled Features), and everybody can get back to work without complaints.

Well, at least those who want to go back to work can do so; there'll always
be people who'd rather complain than Get Stuff Done. *shrug*

Now, on the other hand, let's talk about the JVM, and specifically what needs to change
there if the JVM platform is to be the workhorse of the 21st century like it was for
the latter half of the last decade of the 20th....

---

Enterprise consulting, mentoring or instruction. Java, C++, .NET or XML services.
1-day or multi-day workshops available. Contact
me for details.