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.)