Apologies in advance for quality issues; our crack team of writer just stepped off a red-eye and into the conference. It’s 9:10a and they’re still working on the AV connex. Ah, here we go.

Conference this year is ~15x as big as the first RubyConf. Dave: “For some reason, people keep coming back for more.”

Plenary sessions in the morning, breakouts in the afternoon with Room 3 for work sessions and other non-presentations.

Despite a late start, Dave finished the welcome 10 minutes early. Time for more coffee. And now acquired, having seen Evan (with our awesome Werewolf tees) and Tony Devlin, who say last night’s Werewolfery was good but long. Now up: Marcel, with “What makes code beautiful?” … I’ve seen him do this talk before, but I’m looking forward to seeing how it’s changed over the last few months.

What’s beautiful? Someone volunteered, “My wife!” which drew applause; someone else volunteered, “His wife!” which drew even louder laughter.

Plato asserted that the properties of beuaty are deep and structural which appearances hint at. Discovering what those properties are gives you an understanding of what beauty is.

Marcel’s history: came from literature background, which led him to artificial languages, and here we are. He was early-on interested in looking at ways to make meaning (two sentences can be identical to the last few words and have widely variant meaning) and choosing the properly expressive form for the purpose. Realized over the years of learning and coding that he was really interested in writing what he sees as beautiful code. After evaluating many languages, Ruby rung most true at a subconscious level.

He desired to write software in search of beautiful code, so pursuing code beauty actively gets him to the desired end faster.

Pythagoras, passing a blacksmith, noted that the hammering sound had an appealing quality. As he investigated, he discovered that there were mathematical relationships between the size of the hammer and the pitch of the strike, as well as a relation to musical intervals. This eventually became the basis of the golden ratio.

Thomas Aquinas’ definition of beauty seems the most applicable to software.

Elements of beauty:

Proportion: Marcel invites a roomful of people, largely men, to consider his body. But not in depth. Specifically, his hand and arm. They’re very suited to their purposes. If you modified their proportions in  any way, they’d be less suited and thus less beautiful. Two parts of proportion: ratio of parts and economy of size. If everything were 10x, the ratio of parts would be undisturbed, but the economy of size would differ. [I’d argue that there’s something about the system within which the thing exists that determines how economy of scale fits, and that it’s also arguable that form evolves to suit purpose as we cannot efficiently approach purposes for which we are not suited but if they are critical to our survival, we’ll evolve such that we can]

Integrity: Well-suited to its purpose. A crystal hammer might be beautiful, but it would shatter upon use.

Clarity: Something that’s clear and simple (no more complex than required).

Coerce example (in the slides). Lines of code required can be a measure of proportionality; less is more. How long your unit tests take to run is another [me: and perhaps a better one as it’s a real-world metric which affects how often you’ll run your tests … and the more you run your tests the better your code, right?]. Integrity is how well it behaves while running (does it leak memory?). Clarity is how expressive and readable.

[Rick DeNatale comments that his refactor of the coerce example ended up monkey-patching the String class rather than creating a new class. That might be another indicator of simplicity and how Ruby enables it.]

Kent Beck’s “ Smalltalk: Best Practice Patterns” may not express it as being “beautiful” but it expresses it well.

Rousseau equated “good” with “beauty in action”.

Beauty is a moving target. It’s contextual: it’s not your parent’s beauty.

Bohr: “An expert is a person who has made all the mistakes that can be made in a very narrow field.” [me: this is another demonstration of my “make a lot of small mistakes fast” philosophy]

Ruby is optimized for beauty.

Try to imagine better modes of expression. Ugly things reveal mistakes. Make enough ugly things and you’ll make beautiful ones.

Q: At what level can we apply this?
A: All levels, from a line of code to user experience

Q: [Paraphrased: What’s the role of symmetry?]
A: [Paraphrased: Wide and varied]

blog comments powered by Disqus


02 November 2007


ruby/rails rubyconf 2007