For my last session of JavaOne 2012, I elected to attend Emmanuel Bernard's and Stephane Epardaud's (both of RedHat) "Introduction to Ceylon" presentation held in Hilton Golden Gate 6/7/8.

It has become noticeably quieter in the Hilton since the ending of the morning's Community Keynote and especially since lunch. The Wiki is working great now (no more need to use my Verizon Broadband) and the Hilton's halls seem vacuous with so few people in them. This is typical of such conferences and I have mixed feelings about it: I like being able to more easily navigate the halls and enjoy the speedy Wifi, but there is an almost tangible drop in the energy level as well. It is also with some sadness that I think about this being the last session of the conference. On the other hand, I look forward to having some time to try out some of the things I've learned here and I look forward to seeing some of the presentations I missed here (the "opportunity cost" for attending other presentations).

The speakers stated that "Ceylon is not just vaporware" and said that they created it with the idea of creating a language that Java would be today if built from scratch but with the experience and lessons learned from using Java for many years. Ceylon was "initiated and led by Gavin King" with the intent to "improve upon frustrations of Java." They described Ceylon as a "powerful, readable, predictable" language which has a "platform, modularity, and tooling."

It was stated that Ceylon design highly prizes readability and may, if necessary, require a little more verbosity, rather than rely on tricks, to preserve readability. One of the goals is to make Ceylon very readable to Java and C-style language developers.

Slides with embedded color syntax highlighted code were shown to illustrate Ceylon code. Instead of private, public, and protected, Ceylon allows for either accessibility of shared ("public-ish") or else the default scope is scope-private. Another illustrated difference is that the Ceylon class did not need an explicit constructor. Ceylon provides "immutability by default." The assignment operator is reminiscent of Pascal with :=.

The illustrated example of inheritance looks similar to Java, but with more compact syntax. It was also pointed out that Ceylon has "very few keywords" and many of the items that appear to be keywords are really annotations. The string method is the Ceylon equivalent of Java's toString().

Ceylon does not allow method overloading because support of method overloading makes the compiler and other things more challenging. One common case for overloaded methods is optional parameters and Ceylon supports this via default parameters and named parameters. The second common use case for method overloading is to handle different (sub)types of parameters and Ceylon deals with that case via union types.

Ceylon allows a default implementation to be provided for an interface method with satisfies. This is not a "multiple inheritance mess" because there are no state initialization issues and an implementation must be provided if otherwise ambiguous. It was noted in the audience that this looks very similar to what Java 8 is bringing with interface default methods (brought in for Lambda to be merged into the SDK collections and other libraries).

Like languages such as Groovy and Scala, there are no primitive types in Ceylon (everything is an object, though Ceylon optimizes to primitives underneath the covers when appropriate) and so methods can be called directly on literal numbers. Ceylon also provides type inference. Although it appears to be dynamic, it is actually highly static.

Ceylon aims to avoid NullPointerExceptions encountered at the wrong time (is there a good time for NPEs?). Ceylon helps with this by forcing a question mark (?) the be appended on the end of the type of something that can be null. Once this is done, the Ceylon compiler enforces the variable of that type with the ? to be checked before accessed. Ceylon also has a Groovy-like null safety operator (?.).

Ceylon also supports functional programming. The speakers referenced JavaScript as the "biggest, most successful functional programming language." They showed code snippets using both FP-style closures and imperative-style comprehensions.

Ceylon supports a union type and an intersection type. A good reference on Ceylon types is available in Tour of Ceylon: Types.

Modularity is an important concept built into Ceylon. Packages belong to modules. In a dig on Jigsaw being moved to Java 9, it was noted that modularity was built into Ceylon from the start rather than "in 7, then in 8, then in 9."

The speakers introduced Ceylon Herd (Ceylon modules repository) and talked about the Ceylon Eclipse plugin.

The speakers addressed the Ceylon community. RedHat contributes and the community is encouraged to contribute. They use the "best tools" (github, ant, Eclipse, HTML5, Awestruct, Java, JavaScript, OpenShift, Play!) for contributing to the language. Their "To infinity..." slide stated that there are "five milestones to reach 1.0" with "some features targeted to 1.1." M1 is "done" (minimum all Java-style features and tools/IDE) as are M2 and M3. They expect M4 within weeks and M5 (Ceylon 1.1) is anticipated sometime after that. This is another presentation to add to the long list of presentations in which the speaker(s) requested the community to help them with their project.

One audience member was concerned about the theoretical formality of the Ceylon language. There is a Ceylon 1.0 Specification.

Ceylon supports extending Java classes and even depending on Java artifacts. Ceylon is a JVM-based language, but there is also effort to compile Ceylon to JavaScript.

The presenters stated that one should not use Ceylon for production yet (M5/Ceylon 1.0 has not been reached). However, now's a good time to play with Ceylon and report back any errors or negative features and help influence the language.

I liked a lot of what I saw about Ceylon, but it's still not clear to me why an entirely new language was necessary when many of Ceylon's advantages are common to other newer languages such as Groovy and Scala. There are some neat features to the language, but not enough "that's completely new" moments for me to leave more familiar languages. On the other hand, if I find myself with time on my hands and nothing interesting related to the languages I am already familiar with, playing with Ceylon could be an interesting hobby. However, if I have to choose between playing with and learning Scala and playing with and learning Ceylon, I'd have to favor Scala at this point.

I'd like to see a reason to use Ceylon compelling enough to justify using a language with a smaller community and less maturity rather than using another strongly typed language such as Scala or even rather than using an improving Java. A nerdy part of me really enjoys learning about new languages (hence my attendance last year at the presentation on Fantom and Gosu) and thinking about their assumptions, strengths, and weaknesses, but the more practical side of me likes to know the justification for learning a new language and ecosystem before investing much in that. This presentation allowed me to do the former (learn about a language new to me and give me some things to think about) while only costing me an hour of my time. It was an interesting well-spent hour that met my desire to be exposed to a new programming language.