In Relation To

I've updated Part 3 and Part 11 of Introduction to Ceylon to incorporate some recent revisions to the language and fill in some missing details. I've also added some extra material explaining the reasoning behind a couple of the important decisions we've made.

Folks, all the blogs crowing about the incredible wonders of ohmigod functional programming!!!! — by which you mean using higher-order functions like map() and filter() in some language with ubiquitous side effects — are getting pretty tired. Back in the 80's, Smalltalk guys used to call that object-oriented programming. It's a stupid accident of history that Java doesn't have higher-order functions, and so putting them back in where they should have been all along isn't really some great paradigm shift. Now, there is a lot that the Java family of languages is in the process of learning from the really interesting work on type systems done in the academic community around languages like ML and Haskell, but higher-order functions are somehow the least interesting thing there.

I can't wait to try my hand at creating a Ceylon wrapper for JavaFX 2. The Ceylon language was designed with this kind of problem in mind. And JavaFX was originally designed for a language with some of the same ideas in it as Ceylon. Damn, better get back to work on that damn compiler I keep promising...

Ceylon is a language for defining structured data as well as regular procedural code. One of the first things you run into when defining data formats is the need for micro-languages - syntactic validation for character strings that represent literal values of some data type. For example:

One of the best features of Ceylon is lexically-scoped introduction, which we discussed here, calling it decoration.

We've already discussed the theory behind operators in Ceylon, but I missed out on giving you guys an actual list of them. In compiling this list of operators, we've tried to select operators that make code easier to read instead of harder to read. (Ceylon is supposed to be a language that eschews ASCII-art.) There are a couple of operators in the list that I have doubts about, especially the format operator, $, that is used to format an object to a string.

This is the final installment in a series of articles introducing the Ceylon language. Note that some features of the language may change before the final release.

I'm speaking about Ceylon on Thursday, June 23, at 10am at JAX in San Jose. My last conference presentation on the subject of Ceylon was well-received at the conference itself, but not when subsequently published online, leaving we with the impression that it wasn't very effective. So I'm taking a different tack this time.

In Introduction to Ceylon Part 8 we discussed Ceylon's support for defining higher order functions, in particular the two different ways to represent the type of a parameter which accepts a reference to a function. The following declarations are essentially equivalent:

We've talked quite a lot about union types, and even seen some of their many applications, but one thing I didn't mention is that they can be used as a kind of checked exception facility. Consider the following method declaration: