On Friday and Saturday, I attended the Ruby Hoedown
in Raleigh. This was a pretty interesting event and not like the ones I typically attend. I had one person comment that he was surprised (pleasantly) at Microsoft's interest and sponsorship of the event, however, it really fits in with the direction of the platform, specifically with IronRuby
. Aside from Bruce Tate's
comment about Microsoft being the Satan of the Northwest
, it was quite a friendly event! (I'm just kidding -- I mean, he did say that, but it was meant light heartedly. I think. Judge for yourself when Confreaks
gets the videos posted.) Speaking of Confreaks, the picture to the left is of their setup ... everything from a caseless computer, a few laptops, to multiple PTZ camera setups ... this was cool.
I had an interesting chat with Marcel Molina Jr.
, who gave one of the keynotes. I had a frank discussion about how I'm not quite there yet with Ruby -- for those who are familiar with Ruby, it's very much a cultural thing. You ever see that Venn diagram on Scott's blog about the dream job
? Well, let's replace those 3 concentric circles with "Ruby (the language)", "Rails", and "Culture", and that middle overlapping space is what people talk about when they talk about Ruby. The relationship hardcore Ruby devs have goes beyond the core language.
As pointed out in one of the talks, it's difficult to talk about Ruby without discussing Rails. It's also difficult to talk about Ruby without talking about the culture behind the idea of a dynamic language and the joy behind it.
As I mentioned to Marcel (not in these exact words, but in retrospect) I'm not in that middle part yet. He related a story about him and Python, where everyone said he'd love it and yet, he couldn't make that leap. At some point, he came to that conclusion of, "it's not me, it's you" and moved on. So what place does Ruby have for me? We'll see. There are many aspects of the language I like, but I'm not there yet.
One interesting concept he asked me about was, as an evangelist, if I found it difficult to stay relevant given that I'm not working on production code in a shipping product. The answer to this is absolutely it is! However, I think this problem is with any position, as each position has strengths and weaknesses. For example, a software engineer spends a great deal of time on a project and gains valuable experience in solving a real-world problem, whereas the code I work on is often demo or solves a fabricated real-world problem. However, most software engineers spend a great deal of time maintaining legacy code, and depending on the company, working with technology one or two generations old. Or more. As an evangelist, that's what helps keep me relevant: I'm always working with the cutting edge.
Similarly, folks in academia face this issue. It's particularly difficult to bring real world experience into the academic space -- this is probably why I often felt the most interesting classes were taught by industry pros. But more importantly, it's always a challenge in academia to keep curriculum current.
But I digress. Marcel gave a really fascinating talk about beauty in regards to Ruby. In fact, if you have any interest in understanding the culture behind Ruby (not to mention some good programming metaconcepts to apply to any code) try to find his talk. (I'll post an update to this if/when his keynote is posted online.)
I want to summarize the key message in his talk, but this is sans the poeticism and ironically, the beauty, of his delivery. In simple terms and drawing parallels from the philosophical greats, Marcel proposes that one definition of beauty that we can apply to code is striking a balance between proportion
, and clarity
If we can, as objectively as possible, apply these concepts to our code and satisfy them in balance, we can declare that our code is beautiful. Proportion is about asking the question, "Given the task we're trying accomplish, is this code proportional to do the job we intend it to do?" Marcel relates the idea that proportion is often used in evaluating the elegance and beauty of a thing -- our fingers are proportional to our hand, our hand to our forearm, etc. Since C++ code, for example, is often incredibly verbose (as is assembly, for that matter) it often fails this test -- writing a thousand lines of code to pop a message is not proportional. The idea of proportion, then, is about optimizing the code we write, as well as the idea that the syntax and language itself influences this idea of proportionality.
Integrity is about the suitability of the code to accomplish the task. Again, his analogy (as I recall, anyway) of a crystal hammer was terrific: it may look beautiful, but would likely shatter when used. Is the code robust (and I'll add 'extensible') at solving a certain problem?
Clarity. This one is perhaps the easiest and most objective to satisfy. Is the code sufficiently easy to understand and natural? In simplest terms, is it readable and maintainable? The best test of this that I can think of is, if you gave the code to another developer, can they interpret what is going on?
By balancing these three ideas, it's a starting point -- a framework -- to think about the code we write. As audience members pointed out, the underlying concepts about beauty are surely cultural and may ultimately be in the eye of the beholder. And, depending on the task, one of these may be more important than the others when coding a given solution. Yet, these ideas do offer fun concepts and a starting point for the discussion.
As for me? I'm having fun playing with IronRuby. I enjoy the test driven nature the culture encourages. And regardless of the tool I consider my tool of choice, having more tools in the box is certainly advantageous.UPDATE:
Marcel's talk is posted here