Ceremony vs Essence

I was listening to one of Scott Hanselman's Hanselminutes shows the other day. I can't remember whether it was show 196 or show 197 (probably it was the IronRuby show), but in one of those shows, the conversation turned to Ceremony vs Essence.

I hadn't heard of Ceremony vs Essence before, so I've been learning about it.

Ceremony vs Essence, as I understand it, is a framework for critiquing programming languages. It appears to have been invented by Neal Ford of Thoughtworks, and delivered in a series of conference keynotes in 2008. (Unfortunately, I can't find his keynote slides available online anywhere -- anybody have a link?)

The fundamental idea of the Ceremony vs Essence idea appears to be that, all other things being equal, programming languages should attempt to allow programmers to clearly express the essence of their programs without being caught up in excessive ceremony provided by the programming language.

That is, it appears to be a form of Occam's Razor: an argument for simplicity and clarity, and for avoiding unwanted extraneous clutter.

So, for example, some people look at a statically typed language like C or Java, and observe that the need to define your variables ahead of time, and specify exactly the type of the variable, is "ceremony", and distracts from the "essence" of the use of the variable. This point is made quite well by a pair of essays by Stuart Halloway:

• Ending Legacy Code in our Lifetime (see also his presentation slides)


• Refactoring from Ceremony to Essence

Clink Shank makes a similar point, from a testing perspective, in his essay: Essence over Ceremony in Unit Testing.

I think that, setting aside for a moment the language debates regarding Ruby-versus-Java-versus-JavaScript-versus-whatever, there is clearly a universal point to be made: simpler is better. Simpler is clearer, simpler means less code, simpler is easier to tune, to maintain, to document, to debug.

One of the best aspects of the code review process that occurs during the analysis of a patch proposal on the Derby project is that each successive pair of eyeballs will look at the code and, sometimes, will notice: "Say, you know, you could write this more easily if you did this, or did that, or did such-and-such".

Nobody is a perfect programmer, and no code is ever perfect. The ongoing study, refinement, and improvement of software has no end.

And is ever-enjoyable.