While I don’t spend a lot of time on the .NET platform anymore, I’m still a big fan of Boo. Having cut my teeth on Python many years ago, I’ve always enjoyed hip Pythonic languages and when Boo came out for the .NET platform way back when, I jumped on the opportunity to experiment with it and leverage it at client sites. What’s more, it’s no secret that I’m a fan of DSLs as I do find they can be quite powerful, for example, in leveraging natural language semantics that enhance the “user experience” such as with expressing intent.

Thus, when I had a chance to read Ayende Rahien‘s “DSLs in Boo“, I jumped at the opportunity, baby! Ayende does a great job of of introducing the notion of DSLs (interestingly, there isn’t a ton of literature here specifically about DSLs alone other than Martin Fowler‘s bliki and of course, Wikipedia) in the first chapter, specifically covering the various types of DSLs (i.e. internal, external, and he goes on to define graphical ones plus he reluctantly includes fluent interfaces). What’s more, he also explores why one would want to write an DSL. Here he covers a few reasons, but a quote stuck out regarding one particular reason, which is for expressing

rules and actions in a way that’s close to the domain and understandable to business people

This is, of course, the intent of easyb — that is, to express intentions in an easily understandable language that stakeholders can grasp.

After chapter 1, Ayende goes on to cover the basics of Boo, which, of course, would be needed should you want to actually create a DSL in Boo! It isn’t until chapter 4, however, that you start to get your hands dirty coding DSLs; nevertheless, I understand the need to introduce the various required concepts leading up to chapter 4. Thus, in chapter 4, a few high level examples are covered.

Later chapters go into some details about writing and maintaining DSL code; plus, in chapter 7, he unveils Rhino DSL, which is an open source project that facilitates authoring DSLs in Boo (Ayende, by the way, is a prolific coder — he’s all over the map in the .NET world). Chapter 8 finally covers testing a DSL, which I can attest as quite difficult but paramount to a DSL’s success and stability. He also goes on to cover versioning, which I found quite intriguing as backward compatibility is a double-edged sword.

What I find most interesting is the way in which a base language affects the resulting implementation of a DSL (i.e. the end result). That is, Pythonic DSLs still have the oft complained about “white-space issue.” For instance, here is a code snippet from the book for an order processing engine:

upon auth_denied:
  when preferred_customer:
       delay_order_until_payment_is_authorized "preferred customer benefit"
  when default_customer:
       cancel_order "no money, no order"

Note how the underlying language (Boo) forces the DSL to use spaces (rather than say brackets or def/do/end like calls), what’s more, underscores (i.e. _) are required so as to keep the compiler happy. It’s, in many ways, the same in something like easyb (which is, of course, backed by Groovy), which is essentially forced to use brackets and in one case, a comma like so:

given "a preferred customer", {
  //blah blah
}

Note how Groovy requires the DSL to include a comma between the description String and the Closure. Ruby, by the way, and in the case of something like RSpec, doesn’t have this requirement. For instance, in RSpec:

it "should return item enqueued" do
  @queue.enqueue("test")
  @queue.dequeue.should == "test"
end

Yet, notice the do and end! Needless to say, you can see similar influences in something like Scala too.

DSLs are interesting beasts and they’ve clearly affected productivity on various platforms (need I remind you that Rails is a DSL?). “DSLs in Boo” specifically explores DSLs on a specific platform, yet it’s still an interesting read. Because it’s my bag, I’m definitely looking forward to more books exploring DSLs as a main subject! All in all though, this is an interesting book regardless of your chosen platform. Can you dig it, man?