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
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
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 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."
One audience member was concerned about the theoretical formality of the Ceylon language. There is a Ceylon 1.0 Specification.
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.