The talk is basically split into two parts: (a) what is beauty, and (b) how does that apply to coding?
What is beauty?
After going into the history of what philosophers like Plate, Rousseau and others found beautiful, Molina focusses on the three rules set out by Thomas Aquinas: proportion, integrity and clarity. Things that are beautiful comply to these rules. The examples that Molina uses:
- proportion: suppose the fingers on your hand would be twice or half as long. Wouldn't really be beautiful, would it? Think 'golden ratio' here.
- integrity: a thing has to be fit for its purpose. Take for example a hammer made of crystal. It might look beautiful, but can't do what it's supposed to. The appearance of beauty is not necessarily the same as real beauty.
- clarity: it should be clear what something is/does.
How does it apply to coding?
It's straightforward to apply these principles to programming code. First, let's take a look at proportion. The code for simple functionality should be short. Not long. To add two numbers should be a single call. Molina gives an example here of how that had to be done in assembly. Really way too much coding going on to just do that. Here at work, the phrase "Jan can do that in 2 lines of ruby" are often heard (fortunately a little bit less, lately (pfew)). I feel that's not because I'm a code hacker, but because Ruby makes it simple to do simple things. Perl has the same characteristic, but at a price (I'll come back to that later).
Secondly, there's integrity. Does your code do what it's supposed to do? That's the most widely-used notion of good code: do the tests run? But code that does what it has to do can be still be ugly if it doesn't comply to the other principles. Spaghetti, anyone?
Thirdly, there's clarity. How much of your code can your fellow programmers understand by looking at it for less than a day? The fact itself that you have to explain your code might sometimes indicate that you're violating this rule.
One quirk of applying these principles to programming code, is that there's a clear trade-off between them. Some hacked together code might be very proportionate to what it's supposed to be, but in doing so it might become obfuscated and therefore violate the clarity principle. I must say that I've often found it difficult to understand my own perl code after a couple of weeks of not looking at it. Most of this can be attributed to the fact that the language itself needs you to write less clear code ($_, the way objects are implemented, ...).
When you see smelly code, chances are it's one of these three that are the problem.
Why does this matter?
To paraphrase Rousseau: Good code is beautiful code in action. Creating beautiful code (by the above principles) is no guarantee for good code, but it's a pretty good start...
Note: There's a book on Beautiful Code as well, and apparently there's a chapter by Lincoln Stein on his Bio::Graphics library. Better get my hands on that book for ideas for the ruby version.