The Ceylon Project is an up-and-coming programming language for the JVM, created by Red Hat. Ceylon is currently in active development and just recently reached its 5th milestone. We previously introduced Ceylon by using a simple HTTP server as an example application.
Red Hat’s Ceylon features an improved type system, reified generics, modules, and many more interesting facilities. Under development by Gavin King, Ceylon is intended to improve on top of Java success while correcting some of Java failures. We had the honor to interview Gavin on the prospects of the upcoming Java 8 release, Ceylon, and JVM languages in general.
In the Adventurous Guide to JVM Languages report, along with the introduction to Ceylon, you can find the overview about other JVM languages like Kotlin, Xtend, Fantom and others with the quotes by the authors.
Interview with Gavin King, the Ceylon Project lead.
RebelLabs: How did you come up with the idea of a new programming language for JVM?
Gavin King: Ceylon grew out of our experiences working within the JCP to improve Java, and specifically Java EE. I’ve been involved with several successful efforts to enhance the Java EE programming model, including JPA, EJB 3, and CDI. Eventually, we ran into diminishing returns here, and I felt that it was going to be very difficult to continue to significantly improve the platform without tackling problems that were rooted in Java SE, some in the Java language itself, and many more in the Java SDK. Unfortunately, whereas Java EE was able to reinvent itself, Java SE, for better or worse, has had such a strong commitment to stability that backward compatibility concerns have precluded fixing mistakes. So we felt it would be better to start with a somewhat cleaner slate.
From a slightly technical point of view, major motivating factors were the failure of Java on the client, and the consequent need for a language that works on both client and server, the failure of the Java ecosystem to provide good UI frameworks, and the language-level limitations that make it difficult to develop generic frameworks and libraries in Java.
RebelLabs: What was the programming language that inspired Ceylon the most?
Gavin King: Ceylon is inspired by Java. We’ve tried to make a more powerful language, always keeping in mind that we didn’t want to make it _worse_ than Java – that is, we didn’t want to break the things Java does well, or lose the qualities that make Java such a good language for writing large, stable programs in a team environment.
On the other hand, we’ve also paid lots of attention to other languages we like, which I guess for me would include Smalltalk and ML, and yeah, I’ve even done my time wading through some of the academic literature.
RebelLabs: Are you excited about the features (lambdas, defender methods) in Java 8?
Gavin King: They will definitely make some very common programming tasks a whole lot more convenient. On the other hand, I’m extremely disappointed that the Java SE team has still not managed to deliver built-in modularity after many years of trying. While they definitely deserve praise for the good work that’s gone into Java 8, I think it’s only fair to be equally critical of the failure to deliver on _such_ a critical front. Lambdas are a useful and convenient syntax sugar. But modularity is key to everything Java is about, and is a key cause of its failure in certain areas.
RebelLabs: What are the features you would like to see in Java.next?
Gavin King: Modularity, clearly. Local type inference would be nice, and I think it would fit reasonably into the language. This silly diamond syntax thingy should have been passed over in favor of doing it right.
RebelLabs: Ceylon makes a great deal of modularity and the runtime is built on top of JBoss Modules. Why is that important?
Gavin King: First, because without modularity you can’t fix mistakes without breaking things.
Third, because without modularity you can’t build tools that work with module artifacts and module repositories instead of individual files sitting on your hard drive.
Fourth, because without modularity at the language level, you grow monstrous overengineered technologies like Maven and OSGi. And you wind up with bloated monolithic platforms like Java SE and Java EE (prior to EE 6).
RebelLabs: Probably it is too early to talk about adoption since Ceylon haven’t reached its 1.0 version yet, but nevertheless: do you think Java 8 (or Java.next) will affect adoption of Ceylon in any way?
Gavin King: To the extent that Java 8 rekindles interest in the Java platform, and brings developers back to Java, that will be a wonderful thing for Ceylon and other languages for the JVM.
RebelLabs: How hard it is to get Java interop working for Ceylon? What are the main challenges?
Gavin King: It was (and continues to be) extremely difficult. Ceylon has a quite different type system to Java, and mapping between the two type systems is difficult and painful. We deliberately chose _not_ to compromise the design of our type system to take into account the features of the JVM, since Ceylon is not just for the JVM. Instead we decided to wear the pain of writing code to transform between the two type systems.
RebelLabs: If you had an opportunity to design Ceylon from scratch again, what would you do differently?
Gavin King: For the M5 release, we just redesigned some significant things, so you can check out the release notes! There’s so far nothing that I feel is wrong but it’s too late to fix. Ask me again in a couple of years.
RebelLabs: Some JVM languages seem to have a bit different approach to the “billion dollar mistake” (ie null values). What is the rationale for Ceylon to approach this?
Gavin King: A design principle that we hold very dear is to not build primitive types, special cases, or ad hoc exceptions into the type system. Ceylon has a very powerful type system that is easily capable of representing and abstracting over things like “a string or null” (an optional type) or “a sequence of a string, followed by an integer, followed by another string” (a tuple). So we represent these kinds of things within the language itself, then provide a little syntax sugar for convenience. So we have a class named
Null written in Ceylon, and to represent an optional string, we use a union type
String|Null, which we then let you write as
String?. Or to represent tuples, we have a recursive generic class named Tuple and some syntax sugar to make it easy to use.
Speaking more directly about null, Ceylon’s approach is quite different to other languages, because our null is neither a primitive value assignable to the bottom type (like in Java), nor do we need a wrapper class to represent optional values (as in ML, for example). The reason Ceylon is so different here is that, rather uniquely, Ceylon supports union and intersection types as a really basic feature of the language. Once you start to get the feel for Ceylon, you’ll realize what a really special thing this is.
RebelLabs: Is there a particular aspect of Ceylon you would like to emphasize?
Gavin King: OK, so the language is quite feature-rich, and ticks the boxes, and has just the right amount of cutesy syntax sugar without going overboard with crazy weirdo combinations of ASCII symbols. But that’s not what makes it powerful. What makes it powerful is that these features are layered over and grow out of a very clean, simple, consistent core designed according to _principles_.
RebelLabs: Programming language design is about compromises. Is there any feature that you had to drop because it didn’t fit your constraints or because of JVM limitations?
Gavin King: We’ll see whether we need to drop reified generics. Stef has a prototype implementation that we’re experimenting with now. The question is what will it cost in terms of performance.
RebelLabs: It looks like that most of the recent JVM languages take advantage of static types. Have statically typed languages win the race?
Gavin King: Well, they are certainly where the action is. They’re certainly the most _interesting_ kind of programming language!
The way I look at it is: it’s very easy to design a very expressive language, in the sense of giving the programmer a lot of freedom to write whatever they want in any way they like. Unfortunately, code written in a language like that is impossible for a tool to understand, and even very difficult for other programmers to understand. So if you want to help the programmer create maintainable code, you need a language with _rules_. These are rules that the language designer writes down that the compiler and other programmers use to reason about the code. And these rules get in the way! So there is this struggle to make the language more expressive without compromising the system of rules. And its just fascinating.
RebelLabs: How do you see the JVM languages landscape in 5 years?
Gavin King: I think the JVM platform will remain very popular, and that it will be increasingly common to see people writing programs for the JVM in languages other than Java. It’s very hard to guess _which_ languages will be most the popular. Certainly Java will be one of them.
RebelLabs: In your opinion, how important is the toolset for the programming language (in respect to Ceylon)?
Gavin King: Utterly central. Statically typed languages are languages for tools. The extra productivity you gain from using a statically-typed language with an IDE, compared to using a dynamically-typed language is _huge_ as soon as you’re working with a codebase of any size. I expect that almost nobody will write Ceylon code without the use of an IDE. Though, if you want to try, there is a vim mode available…
I personally invest a lot of my development hours in Ceylon IDE.
RebelLabs: Can you suggest any good reading for the wannabe language designers?
Gavin King: My forthcoming book: “Design and implement your own JVM programming language: from language spec to IDE in just a few thousand commits!”. Bazinga!
RebelLabs: Thanks so much for your time and contribution to “The Adventurous Developers’ Guide to JVM Languages, Gavin. See you soon!