Creating a new JVM language
Last week's announcement of Ceylon brought the focus on JVM-based languages. Ceylon isn' the first JVM based language; nor will it be the last. But the general case of JVM based languages was proposed in Bruce Tate's Beyond Java in 2005, and has been a focus of the Java platform for a significant time, as the list of JVM languages on Wikipedia can attest to. Bruce noted that community is the key to success:
It will need to establish a significant community. You won't see broad adoption unless the adopter can achieve relative safety.
Gavin noted that Ceylon would need a community effort, and has presented a clarification on one of the points he made (regarding Java as a mathematical language). Given the syntax of Java is based on C (and Algol and friends) the comparison was always a bit misleading, though he is now expecting an apology:
Now waiting for a flood of apologies from all the folks who've called me ignorant over this. I'm looking especially at you, Scala fans ;-)
Lockster declared Ceylon, interesting for the wrong reasons. What perhaps is interesting is the fact that there is a perceived need by RedHat for a new language. This might be due to problems with the existing evolution of the Java language (or lack thereof) – by creating a separate language, it may be possible to escape the Java trap whilst still using the performance of the JVM and the invokedynamic bytecode.
One key issue with the Ceylon proposal is the current lack of IDE (or for that matter, compiler or any other toolchain). Any language needs community support; and community support needs freely available (and powerful) tools. Scala has support in an Eclipse IDE, although JetBrains also supports Scala inside IntelliJ. Sven Efftinge also wrote a list of ToDos when considering developing a new JVM language:
- Don't make unimportant changes
- Static typing
- Don't touch generics
- Use type inference
- Care about tool support
- Get rid of old unused concepts
Sven also promotes Eclipse Xtext as a way of creating DSLs with integrated IDE support. This is a set of Eclipse tools which can be used to create a grammar, and then from it, a set of IDE plugins to allow you to edit and view scripts written in that grammar.
Interestingly, even small changes in a language can have significant impacts. Part of the reason why the development of the Java language has been slow is due to the concerns relating to backward compatibility. This is true not just of the libraries but also the language syntax itself. Last year, Brian Goetz published Quantitative language design on the choices in changes to the Java language. In this specific case, the availability of several million lines of Java code allowed choices of implementation (in this case, the type inference for the diamond operator) as to their effects on an existing codebase. For Java, the existing codebase is already present – but for new languages, that isn't necessarily the case.
There are a number of languages which have been ported to run on top of a JVM runtime, including Python (Jython), Ruby (JRuby), Lisp (Clojure) and even Tcl (JTcl). These all exhibit the same behaviour as the existing programming languages but run on top of a JVM based platform. In most cases, these run faster than their native counterparts; but such changes aren't always possible (e.g. see the last flight of the unladen swallow).
Then there are new languages, like Scala, Gosu and Mirah. These may be compatible (to some extent) with the Java platform but may provide similar or significantly different syntax to Java in order to operate. Ceylon is competing with these more than the traditional ports, since the ports are aimed at users of the existing languages elsewhere.
What's clear is that the JVM platform has become the location of choice for experimental languages, whether intermediately translated to Java for compilation, or generating bytecode on the fly. To date, none of the newly generated languages have risen to become the de-facto Java alternate (though there are many Scala libraries now available) – but there is room for growth in all languages, and a rising tide raises all boats.
The key question is how to grow community to the point where the language becomes self-sustaining. To do this, a language must have great IDE support (and preferably, in more than just one IDE) as well as exemplary frameworks (e.g. Ruby has Rails, Scala has Lift) which help drive adoption. Creating a new JVM based language starts at the grammar file, but it's only the start of a long process.
Scala requires a significant up front investment but it will pay off
Set the expectations right. Don't water down the fact that learning Scala is going to be hard - if the beginner does not have a strongly typed, functional language background (Haskell or ML family).
My guess is people look at Scala, get disillusioned and then proceed to create a new language (because Java is lacking).
Good luck to Ceylon
* reiterate on the language
* reiterate on the API and fix damn old Obsolete things (promises about "will be gone across one major version", bah!)
* forget about compatibility - for once
I do realize what backward compatibility is for, but Java overdid it. If you have old code, why to compile it with new JDK? Why to run it there? (I know, I know, performance, etc... but old code without any changes still hits some problems, for instance I had some NIO code that worked on 1.4 but broke on 1.5 - code was broken, but then... even fixing bugs or "grey-area" of execution/API speces is breaking compatibility, or not?)
After many many years they are afraid to touch even API deprecated in JDK 1.1, ridiculous. It's dragging the whole Java down (not the JVM ecosystem, luckily).
I'm looking forward to Ceylon, especially because they want to bring the whole new SDK in. And I'm still want to learn Scala very soon. Maybe then I'll rethink the whole Ceylong thingy, but probably not. We need better Java (many ppl are scared of Scala, whatever the reason is) and Ceylon is closer to Java and may be the best alternative for developers who don't wanna go too far away.
More the Merrier
Who ever builds the best tool support wins. That's my guess.
Mike Hartington Jul 26, 2015