Matz, Jim, and Why are all posting their OSCON presentation materials, which reminds me: here are the slides from my Metaprogramming Ruby talk.

(Oh, and I’ll add to Jim’s request for recordings or podcasts of Why’s performance. I’m particularly interested in a recording of “Setup and Install.rb” from Wednesday night’s FOSCON show.)

I’m back from OSCON 2005, and it was definitely a watershed event for Ruby. It was so great to be there, and to be a part of it. Ruby had a major presence every day of the conference.

Monday, both tutorials—Dave Thomas’ intro to Ruby, and David Heinemeier Hansson’s intro to Rails—were in the large tutorial room, and were packed. At Tuesday evening’s extravaganza, David won the best hacker award, and Ruby got several nods in Damian Conway’s unbelievably entertaining talk. Wednesday morning during the keynote, Tim O’Reilly discussed Ruby’s small but growing share of the programming language book market, and speculated that Ruby might be “the Perl of Web 2.0.”

David led off an eventful Thursday with a keynote on “The Secrets of Rails.” All of Thursday’s Ruby talks were standing-room only, and for three of them people were turned away because there was no place for them. Why’s multimedia extravaganza was moved to a larger and more suitable room (thanks to Nat Torkington and the O’Reilly conference staff) and turned into the most memorable event of any conference I’ve ever seen.

Finally, Danny O’Brien’s Friday “To Evil” keynote topped it all off, hilariously citing Ruby as a notable exception to Gandhi’s famous quotation. Why? Because it went directly from “they ignore you” to “you win” in about three weeks.

Jokes aside, this week alone shows that Ruby has arrived.

In my maturity model of the industry, promoting a maturity model is mere level 2 behavior. By level 3, we outgrow it.

(Bach’s article speaks directly of software testing practices, but it’s all applicable to other development practices as well.)

Ted Neward has rediscovered Lisp and noticed the similarity between many of Lisp’s strengths and some of the stuff he’s been hearing about Ruby. And he’s right. Yes, Ted … Ruby’s a great candidate for building DSLs.

I’ve been particularly interested in this, watching the Ruby community over the past two or three years learn to use the language in this way. I first encountered this style of Ruby programming almost four years ago, with Mathieu Bouchard’s Ruby X11 library, which starts by defining a DSL for specifying X protocol packet formats. Since then, other Ruby developers have come to understand the power of this technique, and are learning how best to use it.

If you use Rails, for example, you see immediately how Ruby has been augmented from within to be a DSL for specifying relational mapping, web application component relationships, validation criteria, URL-to-page mapping, and several other things. I’m preparing a talk explaining how to do such things in Ruby. But one of the most important things to know is that it wasn’t done in a vacuum … it was done in the context of building a real application, Basecamp. That’s the way frameworks, including DSL-based frameworks, should be built. In the the introduction to Paul Graham’s other book, he writes:

You don’t just write your program down toward the language, you also build the language up toward your program. Language and program evolve together. Like the border between two warring states, the boundary between language and program is drawn and redrawn, until eventually it comes to rest along the mountains and rivers, the natural frontiers of your problem. In the end your program will look as if the language had been designed for it. And when language and program fit one another well, you end up with code which is clear, small, and efficient.

That quote doesn’t make much sense to Java or C# programmers, because in those languages the ability of libraries to extend the language itself is limited. But in Lisp, Smalltalk, or Ruby, library design really is language design.

As I prepare my talk, I’ll try to blog more about using Ruby for DSLs – how to do it, why Ruby is a good language for that style of programming, and what its limitations are.

(Oh, and Ted … the night before you bought your book, I also bought a geeky book while on a date with my wife. You and I are scarily alike, my friend.)

Sherlock is one of Apple’s OS X applications that never really lived up to the hype. Once featured prominently in every OS X demo and brochure, it has all but vanished … you have to poke around for a while on Apple’s site to find any mention of it at all.

Why was Sherlock a flop? It was slow, for one thing. And that slowness was very unwelcome when Sherlock itself was not an application you’d want to spend a lot of time in: once you’d found what you were looking for in Sherlock, you wanted to move on to other things. The channel interfaces weren’t especially compelling, but they weren’t especially bad, either, so I’m not sure that was the issue. Another problem was that Sherlock was an integrated application with channels, when a given user, at a given moment, would be interested in just one or two of those channels. It seemed like a heavyweight tool for lightweight tasks. Finally, the API for writing channels was sort of goofy: JavaScript mixed with XQuery, plus Interface Builder for the UIs. It didn’t encourage developers, that’s for sure.

One of the things that came along with Apple’s new product announcements yesterday was an updated set of preview pages for Tiger, the next version of OS X that’s due out in a few months. No mention of Sherlock, not that anyone should be surprised. But what struck me was the new info about Dashboard. They’ve added some new widgets to the lineup. Stocks. Yellow Pages. Dictionary and Thesaurus. Language translation. Flight tracking. A friend who watched the keynote told me that Steve demonstrated a prototype widget from eBay.

Where have I seen that lineup before? Oh yeah! In the Sherlock toolbar.

Dashboard is the new Sherlock.

That’s fine as far as it goes … but will Dashboard fare any better than Sherlock? (I won’t discuss their similar origins.) I think Dashboard solves most of the problems that harmed Sherlock:

• It’s reportedly fast; more to the point, it’s meant to run all the time, letting you get in and out quickly.
• The interfaces are dazzling. Sherlock’s interfaces may not have turned people away, but they weren’t great enough to fuel either user or developer excitement.
• In one sense it’s still an integrated app, but (from what I can tell) it won’t have that feel to the user. You get the widgets you need, and that’s it.
• The widget development model is much nicer, and is already attracting a lot of interest from developers.

I always thought Sherlock was a cool idea with an implementation that didn’t make the grade. I look forward to using its successor.