madbean

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*.