The “Open Conference” format in use here has resulted in a lot of spontaneous last-minute reorganizing of sessions. Scott Guthrie’s much-anticipated talk on Microsoft’s new MVC framework has been pushed to early afternoon, so I decided to take in Roy Osherove’s talk on Test Driven Development. To my surprise I was the only attendee until another guy showed up at the last minute. The three of us agreed to postpone the talk and join everyone else, who seemed to have headed over to the Ruby For Dummies session. Ironically, it was a topic Roy himself had suggested last night when we were all hammering out the conference topics and schedule.
The Ruby talk began with some wisdom quotes from “Matz”, the U.S. shorthand for Ruby’s Japanese inventor. Ruby, says, Matz, is a “balance between simplicity and complexity”. The Principle of Least Surprise says that “less surprise is good”. Ruby’s “surprise-free” ways means “Ruby is the way to “joy”. Matz’s concept of joy, anyway.
Messages, not methods or functions are supposed to be a much better OO implementation than C#. It is returning to OOP’s roots in SmallTalk. That’s ironic to me, because as an old FoxPro warhorse, I recognize this as exactly the way the FoxPro language works. From the perspective of a a dynamic language like SmallTalk, Ruby, Python or FoxPro, too much cruft grows up around static languages like C# just to implement object orientation. The canonical example that always occurs to me is the concept of interfaces. I had some difficulty with this when I first came to .NET 1.0 because all that interfaces are in Fox is a construct to satisfy the requirements of communication across process boundaries to other COM applications. Since Fox only cares about what an object can do rather than being obsessed with what is is, interfaces aren’t terribly useful or necessary. Ruby’s mixins take this still further, allowing a form of multiple inheritance that I’ve often wished for in C#.
Now that I’ve spent five years getting used to the cruft, however, it doesn’t particularly bother me, and you still come down to the fact that compiled applications (e.g., C#) are generally faster than interpreted ones (e.g., Fox or Ruby). Even so, I have to confess that I virtually never ran into practical performance problems in typical line-of-business applications in Fox because everything was compiled to an MIL-like byte-code and as we’ve all found with .NET and Java JITters, the performance of such code can be extremely satisfactory.
Ruby is in my view riding two converging technology “waves”: first, it’s very popular with developers because it is a very low-friction and appealing metaphor for expressing ideas; second, Ruby is slowly moving from a straight interpreted language into runtime environments (such as Microsoft’s DLR) where it can be run as pre-compiled byte-code, which will sufficiently solve whatever real performance issues exist.
Next post in this series is here.
