21 Nov 2008

Syntactic sugar makes the world go 'round

For a long time, I considered Java the C of the Java platform. It's pretty much the lowest-level language you can write code with, unless you're using assembly language (and I remember playing with Jasmin in the early days of Java).

Back in early days, the Java language has very little in the way of syntactic sugar, much like C, except that in C you have a preprocessor, whereas in Java, you had to hack your own (just look at the OpenJDK source code for ample examples of custom preprocessing tools in use). So all the code is ultra-verbose, and (to me) there was a huge mental barrier to writing code of any size, just because I had to spell everything out, every time. (Just don't get me started on the lack of typedef in Java.)

With what syntactic sugar there was, it was too easy to encourage programmers to Do The Wrong Thing™: the availability of operator += for strings meant that a lot of programmers tried doing string-building “the C++ way”, never knowing the difference in semantics between += in C++ versus Java. My feeling on this is that += should not be defined for strings, only on StringBuilders and StringBuffers, with the same effect as calling append() but without the function call syntax.

Of course, once we go down that road, perhaps we would need to provide operator overloading across the board. That, of course, leaves me asking why we don't just use C++ in the first place, perhaps doing a variation of C++/CLI for the Java platform. Oh wait, the Java platform isn't as accommodating as .NET is non-Java concepts; I just can't imagine how, say, the STL would be implemented on the Java platform.


As of Java 5, there were certainly a lot more syntactic sugar for things that were commonly done ‘the hard way’ in the past; type-safe enumerations and generics are two that come to mind, not to mention ‘real’ for loops and variadic functions. And soon (perhaps by Java 7, perhaps not), there'll be closures, which I also welcome.

After all these changes, would Java then be seen as the C++ of the Java platform? (Sorry, this is not meant as a slight to C++; I know that Java does not even come close to approaching the power of C++, but it's the best analogy I can come up with.) Is this actually worth pursuing, or should we all start flocking to more powerful languages, perhaps to Groovy?

I singled out Groovy for one reason: it was a language designed for the Java platform, and has the greatest chance of fitting snugly within the Java platform. Of course, there are things it needs to implement, like annotations, but all in good time. My feeling is that, be it Groovy or some other new language, it has to be a language that allows you to express anything you can in Java; and it has to also allow more powerful ways of expressing them, as well as things that cannot easily be expressed in Java.

I would love nothing more than for programmers to write most of their code in a high-level language, with the bottlenecks separated out into a separate module, which can be written in a lower-level language like Java, for performance. But to get people to switch, that high-level language had better be good to use, and not compromise on features that are available in the Java language.


So, the whole point of that little ramble is that I do think there needs to be a ‘better Java’ for Java programmers. Everything that's easy in Java should stay easy, and anything that's commonly done in Java (and programming in general) but is hard should also be made easy, to further encourage their use. Also, it should link to Java in a seamless way; it should be easy to incrementally convert a project to this new language, file by file.

The language can use either static typing (provided there's good type inference so programmers don't have to spell out types all the time) or dynamic typing; I don't care either way, especially given developments in Da Vinci Machine that will give dynamic languages much better support on the Java platform. I have a feeling, though, that experienced Java programmers will continue to prefer static typing.

The language I envision does not need to be backwards-compatible with Java; for example, the whole insane syntax for anonymous classes can be done away with, especially in one-method cases. It also does not need to function in any platform other than the Java platform. I don't really care about portability to unmanaged platforms or to .NET or to Parrot or to anything else.

Really, like I said, I'm just looking for a ‘better Java’ that's good for most present Java programmers to switch to. And, given the current wide(ish) adoption of Groovy, this ideal language would probably be implemented as a future version of Groovy.

No comments: