Ruby Conference Wrap-Up (Part 4)
After lunch, things picked back up with a presentation by Ryan Davis, entitled “Polishing Ruby: Power Tools and Toys”. As with Austin’s talk earlier Saturday morning, I was too busy paying attention to all of the cool stuff Ryan was demonstrating to take very many notes. Ryan has been busy twisting and contorting Ruby into doing things that Matz surely never intended it to do, and the results were amazing. He covered a lot of ground, and I need to go back and review his slides to see what I missed, but the demonstration that really wowed the audience was his use of ZenOptimize to automatically optimize some code (perhaps a factorial calculator?) and reduce its runtime by about 4x. It’s interesting to consider the consequences of this work in light of the other projects that are attacking Ruby performance from a different (but complementary) angle (e.g. YARV).
Jim Weirich was up next, with a presentation on “Creating Domain-Specific Languages (DSLs) in Ruby”. I took a lot of notes on this content-dense talk, and so I’m just going to hit the high points for this summary. Jim opened with a great demonstration of several non-obvious DSLs. One was the “Siteswap” language, used to describe juggling exercises. (Jim shared that he learned to juggle back in his C programming days, when he had plenty of spare time to kill while waiting for compiles to finish). He also described a DSL for annotating Rubik’s Cube moves, and pointed out that guitar tablature is yet another kind of DSL. In short, domain-specific languages are targeted to very particular problems and solving them well.
Most of us familiar with the history of Rake knew that it grew out of Jim’s frustration with Make. I was interested to hear him admit that until that happened, however, he hadn’t really considered Ruby suitable for DSLs because its syntax was too complex (as compared to, say, Lisp or Forth), that it lacked Lisp’s macro capability, and so forth. He then went into some discussion about how to use Ruby for DSLs (which are best reviewed on his slides) and noted that the goal is to create DSLs that are easy to use, even if we avoid “geek speak” and have to break some programming rules in the process. As Jim said, “The fun part of Ruby is figuring out how to make it behave as it shouldn’t.”
The final talk of the afternoon session was Karlin Fox’s presentation on “System Testing in Ruby with Systir“. Karlin talked a little bit about story-driven development and how it reduces the risk of developing the wrong software. He also described a process in which users write tests in plain English, developers work with the users to design a DSL to encode those tests, and then developers develop the applications. The presentation included a nice demonstration of automated testing of a web site. This was all well and good, but I had trouble identifying exactly what role Systir plays in all of this.
That ended the regular sessions for Saturday. I don’t feel like writing about Matz’s keynote that he gave Saturday evening. Due to a number of interruptions during his talk, things really got off track and it ended up being very frustrating. The conference organizers recognized this problem as well, and hopefully we’ll have some ground rules in place next year so that questions are held until the end.