Beautiful code

Anders pointed me to a talk by some Ruby guy (Marcel Molina) speaking about beautiful code. I must admit that I was a bit sceptical, but Anders was very convincing.

The verdict?

When it comes to ruminating on software design, I think there's a big nasty trap which he unfortunately walked straight into (as foreseen) with few extenuating circumstances (not expected).

The problem is that the field is hidden in a fog of mysteries, buried in what's governed by intuition and tacit knowledge rather than explainable ration. Good programming, hah, that's an art, nobody can tell you how to do that!

What we need here is to be able to talk about the thing. More ration, less intuition. Trying to explain things as beautiful or not is a step in the wrong direction. It's romantic self-indulgence, like when you look at people younger than you and think, people these days... An operational set of values for evaluating code is an essential thing for an aspiring programmer. How can beauty be operational if you don't even know how to argue about it with a fellow programmer?


Beauty? Digital graphic art from YayArt.

In any case, I think his main point can be summed up to: ensure that the code is as small as possible, as clear as possible and does what it's supposed to do. As I mentioned last time I wrote about software design, I think this can be simplified to make it easy to understand.

Save the interesting but tricky beauty discussions for things like this.