BT

Ceylon JVM Language

by Alex Blewitt on Apr 13, 2011 |

Given as a talk at QCon Beijing (which was sold out), Gavin King presented the Ceylon programming language, which he has been working on at Red Hat for the last couple of years. The news was picked up via twitter, and now a number of sites are reporting it, including Lambda the Ultimate, Slashdot and Reddit and YCombinator Hacker News. As a result, Gavin has posted a a post specifically on Ceylon with references to the presentations that caused the stir. He also makes clear that it was never designed as a Java killer:

Nevertheless, I should make a few comments. First, I never billed this as a Java Killer or the next generation of the Java language. Not my words. Ceylon isn't Java, it's a new language that's deeply influenced by Java, designed by people who are unapologetic fans of Java. Java's not dying anytime soon, so nothing's killing it.

As a JVM based language, Ceylon will compile down to bytecode to run on top of the JVM and with Java classes. It has a more restricted form of generics than Java has (no wildcard generics) and supports contra/co-variance in method parameters and return types. This allows Ceylon to perform implicit casting with method return types, although there is no explicit cast operator. Further, since methods cannot be overloaded, there is no need to have methods with multiple types. Keywords in and out on parameters indicate their contra/co-variance support. There's nothing to prevent Ceylon being cross-compiled to other VMs, but the JVM is the initial focus.

Ceylon also introduces named and default arguments for methods, which are a key use case (in Java) for overloaded methods. Methods can also take methods, creating higher-order methods (or higher order functions). Everything is typed (number literals are not distinguished from object types) although the void type is represented as a keyword.

For Java users, many keywords have been changed; for example, instead of implements for interfaces, you now have satisfies. Other keywords have been replaced as well; public becomes shared, with protected and private unused; abstract becomes formal and actual is used for providing implementations of specific interfaces. You can combine interfaces with & instead of , separated lists.

Some operators have been provided; the <=> operator is a shorthand for Comparable's compare() method, whilst == is a synonym for equals(). Some operator overloading is allowable; for example, > is translated to Comparable.largerThan(), which can then be overridden by a specific type. The set of operators cannot be extended (unlike Scala, which permits methods to have non-ASCII names) – but the ones that exist can be overridden by implementation.

There's no null in Ceylon; instead, an Optional type provides an instance of an object, as well as using a type to indicate that it may be optional. The ? suffix on a type is shorthand for an optional value, so String? is a shorthand for Optional<String>.

Ceylon also provides mixin inheritance, as Scala, by allowing methods to be implemented in an interface, although initialization is not allowed. (Some of the project coin for Java 8 may have default methods which provide the same kind of behaviour.)

As many commenters have asked: Why not just use Scala? Gavin has specifically responded to this:

Scala is an interesting language and it's one of several languages that influenced Ceylon. We looked closely at Scala, but we collectively concluded that it wasn't the right thing for us. Personally, I find that Scala's type system is simply more complex than I want or need.

Since Ceylon doesn't support casting, a new keyword case (is...) has been added to a switch statement, which provides typesafe casting to a particular type. If the case block is true, then the body of the case block sees the narrowed type of the original object. If it is not of that type, then you don't execute that block of code.

The keynote presentation also alludes to modularity (a feature missing in Scala as well) but provides no information as to how modularity is handled. It does eschew both Maven and OSGi as “over-complex”, along with synchronization. (See below for Gavin's responses on these.)

Several commenters have identified specific issues with the presentation; for example, “Java is joined at the hip with XML” is factually incorrect and “There is simply no good way to define a user interface in Java” appears to be conflated with ease of use of libraries. Some Ceylon examples show how a user interface might be created in a declarative style similar to JavaFX, though GUI user interfaces are frequently created in other technologies. Others have lambasted the fact that the syntax for defining an in-line function, cited as “stolen from Smalltalk” bears no resemblance to the Smalltalk syntax for blocks. Although both are valid points, these are criticisms of the presentation rather than the language itself.

The future is still open for the Ceylon project, and the presentation was referenced earlier than the materials behind the project were made available. As the conclusion notes:

My team has spent the past two years designing what we think the language should look like, writing a language specification, an ANTLR grammar, and a prototype compiler
  • You can’t write code in the language just yet!
  • We plan an initial release of the compiler later this year

InfoQ reached out to Gavin to find out more.

InfoQ: There are a lot of comments comparing Ceylon to Scala. Where do you see the key differentiators are between the two languages, apart from the fact that Scala allows non-ASCII based functions?

Gavin King: Well, Scala is an interesting language, and is one of the languages that influenced the design of Ceylon. But there are certainly some big differences in emphasis.

Ceylon code is supposed to be readable to people who aren't Ceylon programmers. We've avoided syntactic constructs that we think hinder readability. For example, we avoid the use of cryptic punctuation where words would be better. And we're not going to support true operator overloading. We want to see plain, readable code, not executable ASCII-art.

One important force that helped make Java so successful was the things Java left out. But you need to be very smart here: Java's decision to leave out higher-order function support was enormously harmful. Now, obviously the Scala team have gone down a very different path here and have created a very feature-rich type system. As a general rule I would prefer to solve my problems with fewer, more general constructs, than with more, less powerful constructs.

I've invented some interesting things to make possible a statically-typed metamodel. What I mean is a typesafe version of reflection. I'm not aware of any other language that provides this, though it's possible that it has been done before in some research language that I don't know about. there's no overloading. There are no existential types. And there's no Java-style "null" hidden anywhere in the language specification. All these things would be useful for the interoperability scenario. But they're all otherwise quite harmful in terms of complexity. Oh and, generic type arguments are going to be reified! This opens up some very cool possibilities, but also slightly harms interoperability.

Because we're planning a whole new SDK, Ceylon doesn't make as many concessions in the type system to Java interoperability. In some cases, Java interoperability is going to suffer as a result of that. (Hopefully not too much!) For example, there's no overloading. There are no existential types. And there's no Java-style "null" hidden anywhere in the language specification. All these things would be useful for the interoperability scenario. But they're all otherwise quite harmful in terms of complexity. Oh and, generic type arguments are going to be reified! This opens up some very cool possibilities, but also slightly harms interoperability.

Finally, a major goal of the project is to provide a consistent, elegant, visually appealing syntax for annotations and for defining user interfaces and structured data. You can think of this as support for "declarative" programming, if you like. Now that Oracle have walked away from JavaFX, Ceylon is going to be the language for UI developers!

InfoQ: You note that Maven and OSGi are harmful; what support does Ceylon have for modularisation?

Gavin King: We'll take advantage of a well-defined source and module repository specification to integrate modularity into the toolchain all the way from compiler to IDE to runtime. When you have a more controlled environment, you can get away with much simpler tools. We're basing the module runtime on a project called JBoss Modules that will also form the core of JBoss AS 7. JBoss Modules is a super-simple, cut-down module system, far simpler than other solutions in the space.

InfoQ: Similarly, you note that every object is a semaphore (hence the 'synchronized' keyword) - what plans are there for Ceylon to support multi-threading and locking primitives?

Gavin King: I strongly believe that concurrency, at least until some kind of revolution comes along, is something that libraries should solve. The language doesn't need built-in concurrency primitives. There are a number of good competing patterns for handling concurrency - everything from actors to STM, and the language should make it possible to write libraries that implement these patterns.

InfoQ: You note that Java is joined at the hip with XML - but that's not true of the language; rather, frameworks like Spring utilise XML frequently. Is this what you meant?

Gavin King: I mean that there is no way to elegantly define a user interface, or any other static hierarchical structure, within the language itself. Therefore frameworks have to take one of two paths: define hierarchical structures using procedural code (Swing, Wicket) or resort to XML (JSF and many others).

InfoQ: Why is 'void' a keyword rather than a member of a type?

Gavin King: There is in fact a type called "Void", which turns out to be the return type of a "void" method, but lowercase "void" is a keyword. The reason for that is to indicate to the compiler that no "return" statement is required in the method definition. Note that Ceylon represents some concepts that are part of the language specification of most languages (for example, numeric types, null values, function types) within the type system itself. That's why the type system itself needs to be significantly more powerful than Java's.

InfoQ: For enumerated subtypes, is the set of subtypes a closed set? In other words, given class Node of Branch | Leaf, can I create a third subclass of Node?

Gavin King: No. The purpose of the "of" clause is to tell the compiler that these are the only subtypes, thus letting the compiler validate "case" statements which enumerate the subtypes of a type. If you can think of this stuff as a very convenient way to implement the visitor pattern without losing type safety.

InfoQ: For contra/co-variant types, is using keywords 'in' and 'out' (which have connotations in other programming languages as parameters which return by value) sensible? Will this not confuse developers who are used to 'in' and 'out' parameters in other languages (as distinct from understanding co/contra-variant types, which is useful)?

Gavin King: So we recently noticed that the C# team has independently come up with the exact same syntax, which made me feel pretty confident about it. I certainly think it's much, much better than "+" and "-". Another option would be "produces" and "consumes", but that's going to be very verbose if you have several type parameters. Better to keep it snappy, I think.

InfoQ: You're using 'satisfies' but still using nominative subclassing as per Java interfaces; what's the benefit of introducing the new keyword here?

Gavin King: Java is irregular here. In a class definition, the list of one or more interfaces follows the keyword "implements". In an interface the list of one or more interfaces follows the keyword "extends", which by coincidence may also appear in a class definition where it means something completely different (it is followed by a single class). Ceylon is regular. Lists of types always follow "satisfies". The keyword "extends" is always followed by an expression that instantiates the superclass.

We think syntactic regularity is very important.

InfoQ: Finally, what is the plans for getting this out into the open (other than e.g. QCon)? Are you going to make it available via GitHub?

Gavin King: Yes, once we're ready with the M1 compiler release, it will all be on GitHub. But I don't really want to release the grammar and type checker without having the backend to go along with this. To be honest, I wasn't expecting this to hit Slashdot quite so soon ;-)


The presentations are available at: introducing project Ceylon and the Ceylon type system. What do you think of Ceylon?

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Two remarks by Sven Efftinge

1) One can say a lot about Scala, but stating "As a general rule I would prefer to solve my problems with fewer, more general constructs, than with more, less powerful constructs." just tells me that King doesn't know it.

2) If King had used Xtext (www.xtext.org) to implement his language he would probably have been able to show a working compiler and an IDE. Unfortunately Xtext doesn't yet clean up your language design :-P

Re: Two remarks by John DeHope

This is the first language since Fan (now Phantom) that interests me. It seems like they are getting closer to what I need than Phantom did. Importantly, all the rationales he sites are ones that speak to me. No language is going to please everybody, but this one might just please me, and honestly what else can I ask for? One question I haven't seen answered is: why the different syntax for calling a function or method without named parameters using parenthesis, versus calling it with named parameters with curly brackets. It's confusing that when you see a curly bracket, it might be a definition, or it might be a structural block, or it might be a call.

Not a knock on Ceylon specifically, but.... by Robert Dean

Lately, it seems like new languages are popping up all over the place. Language X doesn't do feature Y quite the way the Fred the Uber-programmer wants, so they develop language Z that does what they want.

This is okay, and it's an insanely good thing from a computer science perspective, but I wonder if we're building the proverbial tower of babel? What happens if all of these languages gain widespread acceptance?

Why several method call syntaxes by Emmanuel Bernard

One question I haven't seen answered is: why the different syntax for calling a function or method without named parameters using parenthesis, versus calling it with named parameters with curly brackets. It's confusing that when you see a curly bracket, it might be a definition, or it might be a structural block, or it might be a call.


Hi John,
There are a few ways to call a method in Ceylon:

- one is the classical Java / C-style approach which is very familiar to most of us

- the curly bracket one is here to blend in perfectly with the hierarchical structure syntax and make it look like a declarative language: there are on top of it a couple of syntaxic sugar to even improve that. I believe there are examples of that in Gavin's presentation.
A side benefit is to get a natural sequence instantiation syntax String[] names = { "Gavin", "Emmanuel", "John" };

- the smalltalk-like syntax is here to create DSL and other generic control loops
Boolean allAdults = forAll (people) every (Person p) (p.age>=18);

Arguably, the various approaches will puzzle people at first and we will need refinement but so far we think that the benefits overweight the drawbacks by far. Hierarchical structures and DSLs are two important goals for Ceylon.

It's confusing that when you see a curly bracket, it might be a definition, or it might be a structural block, or it might be a call.


Note that in Ceylon, because of the regularlty, these are similar or the same. Remember the "constructor" of a class is its definition block itself, there is no notion of Java constructor.

Hope that helps

Why not Scala? by Mario Fusco

Scala is an interesting language and it's one of several languages that influenced Ceylon. We looked closely at Scala, but we collectively concluded that it wasn't the right thing for us.

Yes but why? What does it mean that "Scala's type system is complex"? Maybe it means just: "I am not able nor am I willing to invest the effort to come to to understand this."? And it is believable that this can be the only reason to create a completely new language?

Re: Why not Scala? by Gerald Loeffler

Yes but why?


I agree that what Gavin gave as the reason for not using Scala is just a value statement and not a well-argued explanation.

Additionally, i think that Scala stands out due to the rigour it brought to the design of the type system, and that that rigour resulted in the kind of "complexity" that is often criticized (including by Gavin). What i mean to say is that Scala's "complexity" in this area is essential complexity and not accidental complexity - so the only way to make the type system less complex is by reducing its rigour. Having said that, i do trust Gavin to know where certain rigourous features of the type system are of little practical relevance and can hence be traded-in for better comprehensibility.

cheers
gerald

www.gerald-loeffler.net

Re: Why not Scala? by Mario Fusco

So, for my understanding, the recipe for creating Ceylon has been: take Scala, make its type system weaker, its visibility and access levels less rich, remove implicits and lambdas, throw away the actor model, make it syntax slightly more verbose, and that's it.

If so ... well ... no, thanks :(

Re: Why not Scala? by Alex Cruise

Mario, it's easy to forget, but the actor model isn't a language feature, it's a library that's made possible by a relatively small number of language features, like PartialFunction literals, Nothing-typed methods not being expected to return, etc.

Re: Not a knock on Ceylon specifically, but.... by Morgoth Melkor

I agree with your sentiments...

But no it is not insanely good thing from Computer Science perspective (May be for the language author's knowledge to know the compiler fundamentals) but all these languages do the same thing under the hood. It is like a birthday boy getting the same gift over and over again but with different wrappers.. We can be excited seeing the wrapper for a while but then nothing else matters.

Interesting by Jason Carreira

Well, obviously we can't take this for a spin yet to try it out, but in terms of direction I like what I'm hearing. This hits the problems I have with Java (no function types, no easy instantiations, null checking everywhere, etc) but keeps the focus on readability, simplicity, and big team maintainability. They sound like they're trying to avoid the problems I have with Ruby and Scala, i.e. trying to be too clever by half.

Seriously, I know you may love fancy language features when you're using them in your own green field development, but try going back and maintaining or extending someone else's codebase when they've sprinkled a lot of magic in there that turns up affecting code a long way from the source.

What this really is. by Clinton Begin

Warning: Speculation and conspiracy ahead (needless to say, strictly opinion)... :-)

So far every blog post and article I've read talks about this like Ceylon is Gavin King's pet project (as Hibernate was 10 years ago). But the reality is, he works for Red Hat. He's probably the right guy to have on it, both because he's a smart guy, and also because his name will help promote the product.

But this is Red Hat's project. Red Hat's money. Red Hat's software. Red Hat's language.

I think a storm is coming in the language and tooling space. The pendulum has swung back and companies are digging in their heels and drawing lines around their territories. With Oracle at the helm of Java, companies have lost faith not only in the JVM and its future, but also in the investment they're making in the Java language. And they're worried about the mind share that Java currently has.

I predict that languages will become proprietary again very shortly, as they were pre-Java. The choice of language will primarily be driven by your platform choice (also similar to the pre-Java days).

Oracle, WebLogic, JEE --> Java
VMWare, Spring, Grails --> Groovy
Red Hat, JBoss, Seam --> Ceylon
Microsoft, Windows, .NET --> C#, VB.NET, F#, etc
Apple, iOS,OSX --> Objective-C
Google, ??? --> Go? Python?

IBM is one that remains a mystery. Perhaps they'll just stay out continue to offer services for all of the players while they battle it out.

But, the companies do want to own the language (and obviously the tools that go with it). They want YOU to invest brain space into it. Learn it. And they want you to despise everything else. Zeal for a language is the ultimate lock in. This isn't about whether one language is good or bad. It's about who controls the language and the people who know and love it.

Java has become too ubiquitous. The Java language is more "portable" than the bytecode it generates, and that scares companies.

They don't care about being able to pick up a class file and drop it on Windows or Linux. They care about being able to pick up a developer and drop them on Seam or Spring.

There are still a lot of "random pieces" floating around to be scooped up: Scala, JRuby, Mirah, Clojure.

While all serious alternatives, and wonderful technology, they won't have any "blue suits" selling it at the boardroom tables. But more importantly, they won't have the commercial backing to help them progress. I'm not trying to pick on Ruby when I say this... but why is Ruby still stuck at 1.8.7, three years after The Ruby Programming Language (book) was released, discussing Ruby 1.9? Even JRuby just recently "almost" fully supports Ruby 1.9. Money matters. An such languages will not have enough to compete.

I kind of like that about Ruby though. I took a 3 year break from it, and recently returned only to realize that I haven't "missed" anything. :-)

But it's what is running through my head when I look at Ceylon. It's Red Hat's language for Red Hat's platform. If they can gain momentum and mind share, then a VM will follow shortly after. I think it's crazy to think that these companies are "okay" with depending on Oracle's virtual machine and language.

Anyway... just my speculation and conspiracy theory. Have fun with it, but don't take it too seriously.

Cheers.

Re: What this really is. by Gerald Loeffler

Anyway... just my speculation and conspiracy theory. Have fun with it


thanks for the spine-tingling! But alas i'm not buying any of it ;-)

I think what we're seeing is not sinistre design but the expression of confusion and disorientation that comes with an ongoing change in perspective/ideology/viewpoint in software development: the end of the Java/C# hegemony is already certain, but a new king has not been crowned yet, so the candidates scramble for influence and mind-share.

Re: What this really is. by Clinton Begin

Just to clarify, I don't think it's sinister. But I do think it's in each company's own best interest. I should have said that more clearly. And for the record: I don't blame them for what they're doing. After all, they have shareholders.

I'm just not sure that people realize that this is not entirely for the sake of innovation, nor is it altruistic.

Cheers,
Clinton

Right track by Sony Mathew

Gavin is on the right track, filling a large void in my opinion. All the new languages that have cropped up recently are a little off. A language with a strong type system but not as complex as Scala is practically being beckoned by the forces of nature and might just hit that sweet spot we all have been waiting for but haven't bothered to do anything about cause Java still kicks gut.

"Syntactic regularity is very important." - Right on!

p.s. Don't like the idea of eliminating overloading however.
Sony

Scala by Jonathan Locke

Scala is a big step beyond Java in may respects and I do like a lot about it, but I think Gavin is right that it is highly non-intuitive. You can't look at Scala code and guess what it does at all. You have to be initiated into Scala thought, which really requires a very detailed understanding of the language spec and an understanding of academic computing jargon and history to some extent. You also have to be initiated in every redefined operator, DSL convention, implicit conversion, and so-on being used in a given project (which would be a prohibitive task on many projects I've worked on).

It would appear that Ceylon is a reaction to this and is attempting to democratize a lot of what Scala does. Scala is very much designed for the elite while Ceylon is going to be inherently more accessible to the masses. Whether the people on both sides of this argument want it or not, I think we are going to have a world with both types of languages.

I don't think it's too late for Scala to make a bigger impact if it wants to (and I don't think that it does, otherwise it would not be academic in its syntax and specification), but if it wants to escape wild startups and the stuffy halls of universities and become a dominant language, it's going to have to support a mode of operation with far greater legibility where dangerous features can be turned off in certain scopes and full names can be used instead of arbitrarily defined operators and funky abbreviations. There are contexts where spelling-it-out is king.

Which do I prefer?

I'm not sure I like Ceylon better than Scala because part of me is a populist and part of me is an elitist. I may opt for Scala on small projects with elite programmers and Ceylon (or some other future language like it) on projects with dozens of programmers and millions of lines of code. I would be frankly quite terrified to see a Scala project that size. God knows what any given section of code might actually do. Yet Scala does have a certain cool factor even if it is mixed with a retro Perl-ish syntax at times.

Ceylon and Kotlin merging by Nikolay Rychkov

Please vote for Kotlin and Ceylon merging in Kotlin bug tracker. Vote

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

16 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT