I'm in the processes of wading through the language changes in the new
JDK 1.5 early access compiler.
I've always enjoyed a reputation as a language lawyer, so I probably have a
brain that is geared towards understanding new syntaxes and
languages. In fact, I'm really interested in what are often considered
"hard" languages, like Lisp and Dylan.
So when I say that the Java language is becoming a whole world more complex
you can imagine I'm not making an understatement.
(As to why Java is getting more complex, see the end of
this article. First, I have some meandering to do.)
Languages designed For the Masses (LFM) and Languages designed for
Smart People (LFSP)
If you have a couple of minutes, I recommend quickly reading
this
article on Paul Graham's site.
Mike Vanier seems to have a stone to grind against the LFM wheel; but
I think he has interesting things to say about both camps.
Luckily Java is a LFM.
Java is (currently) a LFM, pure and simple. In fact, more than any
other factor, I attribute Java's success as a language and a platform
to it's simplicity. No header files, an easy compilation process, no
multiple inheritance, primitives where you might the performance, no
"in-out" parameters, no operator overloading, no-nonsense static typing. It has garbage
collection! Just enough syntax and semantics to do good,
sound, middle-of-the-road OO designs and implementations; in an
easy-to-recognise C++-like syntax (curly braces).
(Okay, as an
equal-first for Java's success I might also nominate the presence of a
good standard library. But this makes Java simple too... simple to
learn and use.)
I love Java's simplicity; especially since when I applied for my first
Java job, I knew nothing about Java and simply read the first edition
of "Java in a Nutshell" the night before the interview. That was
enough to convince some people that I
knew about Java. ;-)
If you look at a few lines of Java code, there is a good chance you
can work out exactly what is going on. You don't have to ask yourself
"is that plus-operator being overloaded" or "is that string immutable
or not"? Java gains many strengths just from it's simplicity alone.
If Java became a LFSP, would that be bad?
Let me quote something from the above article:
LFMs deliberately restrict the abstractive power of the language,
because of the feeling that users "can't handle" that much power. This
means that there is a glass ceiling of abstraction; your designs can
only get this abstract and no more. This is reassuring to Joe Average,
because he knows that he isn't going to see any code he can't
understand. It is reassuring to Joe Boss, because he knows that he can
always fire you and hire another programmer to maintain and extend
your code. But it is incredibly frustrating to Joe Wizard Hacker,
because he knows that his design can be made N times more general and
more abstract but the language forces him to do the Same Old Thing
again and again.
As a seasoned Java programmer, I have felt that "frustration of Joe
Wizard Hacker" many, many times. I've wanted parametric polymorphism
(generics), or multi-methods (multiple dispatch), or real closures, or
first-class functions, or
continuations, or compile-time-loose but run-time-strict typing.
So, on one hand, I'm happy Java is a LFM. But the
Wizard Hacker in me wants out (that is, I want to do Wizard Hacker
work for my day job). But is that a good reason for turning
Java into a LFSP? No.
But it may turn out that it doesn't matter if there is a good reason or not.
Java has already landed and complexity won't displace it
I like Robin Sharp's
taxonomy
of the programming language life-cycle. Robin puts Java somewhere
between Maturity and Inefficiency (I'd say we haven't quite hit Inefficiency
yet); that is, the language and libraries
are capable of delivering profitable solutions, tools have matured and
there is a particular focus on functionality rather than efficiency
(in order to reap profits).
I think we can agree that Java has already hit the mainstream, that
there is a large body of Java code and coders, and that in many
organisations there is a large (and varied) level of inertia against moving away from
Java. Sun is going to be adding complexity to the Java language; you
may not want to use it, but there is nothing you can do about it. Java
already has you on it's hook, and no amount of wiggling at extra
complexity will shake you off, if you still need Java.
What complexity am I talking about?
I like all the little nuggets that are being added with JDK1.5, but
there are a lot of little nuggets in there. The next time you look at
a few lines of Java code, will you be able to remember even these 13 additions
to the simple core language?
The new for loop syntax.
Auto-boxing on assignment and parameter passing.
Unboxing may cause a null-pointer exception.
Which method of a set of overloaded methods gets called in the
presence of auto-boxing.
What method is being called when some methods may have been "statically" imported.
What identifier is referred to when enum constants have been statically
imported.
What is going on when methods have been added to individual enum constants.
What the new angle-brackets mean when defining a generic type.
What the angle-brackets mean when using a generic type.
Where the angle brackets go for a generic method.
Remembering that generic methods may throw generic exceptions.
Remembering that you can't use reflection to determine the
parameterised types at runtime.
Understanding what happens to your generic type when someone simply
"casts it away".
(And that's not even mentioning the "variance" proposal to Generics!)
That's what I mean by complexity.
So what does all this mean?
In short, I'm saying "get ready". Java is getting harder. You use
Java. Java is getting harder *for you*.
Previous Topic
