Plans for Strategic Primer in Ceylon

For a while now I’ve been excited about a new programming language, Ceylon. It’s designed to run on the Java Virtual Machine and be interoperable with Java, but to fix many of the faults of Java that I find most troubling, and introduce some new features I’ve often wished for. As soon as it becomes usable—which I hope will be with the release of the second milestone version of the Eclipse plugin—I plan to begin porting the Strategic Primer assistive programs to it. Here’s a few highlights of the features that make this so exciting for me:

First, what I call “automatic casting”: if you determine that an object is a particular type in an if statement (you’d do this using an instanceof operator in Java), Ceylon effectively changes the visible type of the object to that type for the rest of the block.

Second, guaranteed null-safety. I’ve had what feels like more than my share of segmentation faults and NullPointerExceptions in my life; Ceylon requires that anything that could be null be marked as such (using its powerful system of union types, which I’ll talk a bit more about later) and then checked (using what I called “automatic casting” a moment ago) before being referenced.

Third, enumerated subtypes. In Ceylon, I can say “this is a list of all the subclasses of this (abstract) type” and then, when I have an object of that type, use a switch based on which subclass it is. The compiler will even object if I add another subtype later and miss one of the places where I use a switch this way. This is probably the most important incentive for switching: adding a new kind of model object requires adding support for it both to the XML reading code in the controller and to a few places the view, and it seems like I often forget something.

And fourth, “mixin” inheritance. In Ceylon, interfaces are allowed to define concrete methods, though they’re still absolutely stateless. This will let me avoid duplicating twenty lines of boilerplate for a one-line difference just to share behavior between classes that, for their main behavior, have to have different supertypes.

I have hopes for powerful, expressive, and intuitive I/O and GUI frameworks, but even if I have to write the view code by calling Java, these and other features that already exist or are high on the roadmap make switching to Ceylon a fairly easy decision for me.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s