Skip to main content

The Next Big JVM Language

Posted by cayhorstmann on September 24, 2010 at 6:47 AM PDT

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.

Related Topics >>

Comments

The NBJL is java with usable APIs

Seems to me the main reason why developers migrate to Ruby and the like is that the APIs are so much better. Java programs become just too large mainly because the APIs are poor, to say the least. Too many APIs are good at exposing the nitty-gritty details, possibilities and options of the domain, but forget to make the common things simple. Unzipping a zip file to a directory, for instance, can be done in a single 3-parameter command on the command line (and probably in just about any other programming language operating on zip files as well), but the java API requires you to write around 50 lines of code (!) with nested/recursive iteration having conditionals inside. XML handling is another example.

If the APIs were repaired (hopefully using closures where appropriate, when available), I think even a backwards compatible Java could be the NBJL.

Ruby also has a lot of traps

There are also a lot of things that are not so obvious in Ruby. How to declare default values for optional parameters for example, or differences between quotes and double quotes, the %w shortcut, those names with special meanings, etc... There are so many of them. I think that Ruby is the new Perl, because it is completely object oriented, and it it arguably much more consistent. But IMHO there still are a lot of things that are there because somebody said "why not"? And about Java, I'm using generics everyday, and if you don't want to do rocket science with it, it's no hassle, and very good to avoid runtime cast exceptions. And if somebody do not know what inner classes are... well I think he must go to a programmers class. You need maybe 15 minutes to understand what they are doing.

What scala needs to be the next NBJL

In order for Scala to be the NBJL, people need to write books about using existing frameworks, with scala as the underlying language for code samples and the like (without excursions into langauge features that only complicate things). If you do that, then people will see how simple Scala is to work with, and they'll accept it as the NBJL. (Oh, and by all means provide Scala wrappers for common libraries so that taking advantage of Scala's simplifying features really is simpler than doing things the Java way.) As long as the focus is on the advanced features that Scala provides, people will see Scala as complex. If people can see Scala as Java with a few simplifications, Scala can become the next NBJL. (And books about Scala language features aren't the way to do this -- books about doing different kinds of common tasks/common problems in Scala are.)

agree

I completely agree. I once was curious about scala and I went to some sites to see what it was all about. The description of scala was pretty impressive .... until I took a look at the code samples. Then stuff started to look like perl. Then I just went to another website.