The Next Big JVM Language

Stephen Colebourne has a very interesting article on the Next Big JVM Language (NBJL). The comments are good too. (I was going to add this as a comment to his blog, but it was rejected as spam. Maybe jroller is onto something...)

Stephen defines the NBJL as a language that targets the JVM and is broadly adopted, i.e. the dominant language on the JVM. He argues that such a language must (a) fix the flaws in Java that are now obvious and (b) be useful and comprehensible to the "typical developer". In his opinion, this rules out Clojure (too Lispy), Groovy (too slow), Scala (too complex), and Fantom (type system too weak). He argues that the NBJL should be Java, or rather, a backwards-incompatible version of Java with the cruft removed and a relatively modest set of improvements. Which, at the speed things are moving, should be ready right around the year 2525. If man is still alive.

Just kidding. I can see his point. But I don't think it's going to happen.

The blog comments were mostly about Scala. It's too complex! It's not! It is too! Not!

So, it seems as if Scala has become the NJL to beat, and the question is whether it can become the NBJL.

A sweet spot of Java has been it's "blue collar" nature. A working programmer could understand all aspects of the language. Contrast this with the byzantine complexity of C++ whose users at some point simply must declare their faith in the library designers and hope for the best.

At least, Java 1.0 had that ideal "blue collar" nature. Post-1.0, not so much. I have met plenty of programmers who didn't understand inner classes, serialization, reflection, or, of course, generics. Ok, make that Java 1.0 minus monitors--lots of working programmers don't understand those either. In fact, I'd add to Steve's list of features that the NBJL must have: "Blue collar concurrency".

Creating a "blue collar" language isn't something that happens every day.

When done by "blue collar" people who have sketchy knowledge of programming language theory, the result is often problematic. Look at PHP--I trust that I won't have to elaborate... Or Groovy, many of whose properties (particularly in the MOP) are under-specified and constantly shifting.

Few "white collar" people have an interest in designing a blue-collar language. They give us languages that dazzle us with their brilliance and innovation. After all, that's what a researcher is rewarded for.

As white collar languages go, Scala is better than most. Much attention is paid to compatibility with the JVM, the Java libraries, and the Java tools infrastructure. This isn't the "just shut up and use Emacs" crowd.

Still, in order to be a happy user of Scala, you will need to put your trust in those people who forever go on writing near-incomprehensible blogs about monads and category theory. For example, as a user, I have no desire to actually understand "higher kinded types", but I happily take the result: By calling someCollection.someMethod, I get back another collection of the same type that I started with.

Like I said, plenty of Java programmers don't really understand Java, but they muddle through anyway. It is entirely possible that these programmers will be just fine with Scala. They would use a subset of the language, learn to stay away from the dark corners, and avoid the people writing those category theory blogs.

I think the people who complain most about Scala are the ones who would like to be able to grok the whole language, without wanting to learn more about programming languages than they already know. This approach worked great with Java 1.0, where the hard parts—GC and the JIT—are pretty well hidden. But maybe that was an outlier, and we just have to accept that the NBJL isn't going to be as simple.