This is Day One of Rubyconf 2007, held in Charlotte. The flight was pretty smooth last night. Clear weather, cool. For some reason, we still took off about 20 minutes after the scheduled time. I guess that's typical for flights to be arbitrarily delayed. At least, it landed on time.
The sessions at Rubyconf are being held much like Railsconf. There are morning sessions where everyone attends. The afternoon sessions break up into three groups, two with talks, and one more that's freeform.
The first talk of the day was given by Marcel Molina whose name, of course, reminds me of Alfred Molina (the actor). Marcel's talk was on the beauty of code. Since he had studied literature in college, he's long been interested in how humans define beauty, though in this case, how notions of beauty apply to code.
Several thoughts. I wonder if beauty is a social construct. Someone pointed out that his wife was beautiful, but he couldn't define why. All of advertising is meant to induce us to buy things, and sex sells. So advertisers want beautiful people.
So do people who make television programs. In fact, there are so many beautiful people in television, we don't even realize, except that we think that people are hot on this show, and that is not the norm of the world.
As Marcel points out, beauty can be transitory. What is a beautiful woman to someone from the 1500s may not be beautiful now.
To me, beauty has some transitory nature.
Yet, there are some things that feel like they hold on even years after they are discovered. Marcel points out Pythagoras's theorem (who also defined beauty) and that theorem is beautiful thousands of years later.
He points out beauty in language, but he points mostly to English. Is French more beautiful? Japanese? Are the equally beautiful? Can they really be equally beautiful?
I ask this because he eventually says that Ruby is beautiful, and therefore other languages, presumably Java or FORTRAN are ugly even if, at one point, they might have been considered beautiful.
He points out how assembly was the standard for a long time, and so the simple construct of a switch statement must have seemed beautiful at the time.
I wonder if beauty can only be produced by individuals. We think of artists as working in a solitary fashion. We don't think of art by committee. Maybe we can write code in solitary fashion, beautiful code. Can we write beautiful code if someone else is dictating what the code must do? Might it create mess that wasn't intended?
For example, at one point, the Communist party in the Soviet Union and China believed in utilitarian art, that glorified communism. Was this beautiful? What if you requested a person wear this bland uniform instead of a lovely outfit? Or if they smiled more naturally? Or more unnaturally?
He gave a particularly simple problem of converting strings to various data types. In particular, true, false, integers, dates, and then strings. What if he had ten types to convert? And it had to escape stuff? And it had to plug in different languages so true/false could also be vrai/faux.
You have to support internationalization! And this crappy date format, which odd exceptions.
As some point, all those constraints work against you to impact beauty. There's something to be said about simplicity, or even symmetry, in beauty. So the highly ornate decorations of buildings from old Europe or India might not be simple, but have beauty, partly because the constraints don't impact beauty.
Beauty is also comparative. We talk about beauty relative to things that are ugly. Can beauty mean anything if we aren't comparing? Is a person beautiful because they are beautiful relative to something that we consider ugly?
As related to code, beauty comes from making "mistakes". Writing code that feels ugly, and comparing it to code that feels clean, and starting to figure out principles of good code.
There's a sense that beauty refers to something permanent, as opposed to say, infatuation. So people always say you might fall in love when young but that is merely infatuation, and youth lacks maturity and lacks a sense of what love truly is.
That's all nice and touchy-feely, but implicit in the talk about beauty is that this is something we appreciate and should feel happy about.
And that's fine. After all, beauty, as it pertains to code, as touchy-feely as it is, attempts to address the question "what makes good code?". And people do strive for that, even if they aren't quite sure what that is.
Mathematicians and physicists talk about beauty and elegance in math. Beauty apparently need not be understood by all, even if some people treat beauty as if it were inherently universal, independent of human opinion. It's not. Beautiful code still looks like gibberish to the average person.
I have to hand it to Marcel, a guy who made the leap from literature to coding, for making me think about beauty in code. I have a book called
Beautiful Code, which they were handing out copies during a raffle, and he gave some basic criteria for beautiful code, outlined by ideas of beauty from one Thomas Aquinas.
Marcel (and Thomas) said beauty consisted of proportion, integrity, and clarity. Basically, is the code nice and short, does it do what it's supposed to do, and can you tell what's going on? That is a practical measure of beauty, at least as it applies to coding.
Beauty is one of those things that it's hard to talk about to beginning programmers, because beginning programmers simply try to get the code to work. They don't care that it's convoluted, cut-n-pasted to death, not terribly robust, or perhaps doesn't even solve the problem. And in the end, programs don't have to be particularly beautiful, but the reason we raise the issue is that this unnatural way we write, that is,
code, is something people often hate to read.
Indeed, in the early days of code, people would only do things themselves. They wanted to
know how to do something, and they weren't prepared to read other people's code which has some weirdness to it. These days, it's important to learn how to read other people's code, and so beauty is an issue, because it really means readibility, but in the cause of getting stuff to work.
It's a complex issue, but it's interesting to discuss.