Domain-Specific Languages

I just read this post from Jeremy Miller, and was happy to see that he suggested adding embedded domain-specific languages (EDSLs) to Roy Osherove’s ALT.NET Hot/Not list. For those not familiar, an EDSL is a creative use of a programming language that makes the code required for a specific task more like natural language. (Fowler has a much better definition here.) The first time I really saw the power of an EDSL was when I used NUnit 2.4, which lets you type things like:

Assert.That(foo, Is.Not.Null);
Assert.That(bar, Is.Equal.To(42));

After seeing the way Guice used the Builder pattern and an EDSL to drive its type binding mechanism, and after reading this great paper on the evolution of the JMock EDSL, I decided to implement my own in Titan.

Titan’s EDSL is really what gives the contextual binding system its power. For example, compare this:


To this (similar to an early version of Titan’s XML configuration):

  service="MyCompany.ProjectA.Services.IService, MyCompany.ProjectA, Version="
  implementation="MyCompany.ProjectA.Services.ServiceImpl, MyCompany.ProjectA, Version=">
    type="Titan.Kernel.Conditions.MemberNamespaceStartsWithCondition, Titan.Kernel"

The latter is much uglier, slower, requires much more effort, and blocks you from using the power of the IDE for statement completion and type-checking. Not only that, but I (or more likely, an unlucky developer that decided to use Titan!) would have to create a different condition type for each possible condition. There wouldn’t be the slick re-usability that Titan’s EDSL has via its ConditionBuilders. The way the internals of Titan’s EDSL works is particularly interesting, and may be the topic of a near-future post.

EDSLs are starting to gather steam in other developer communities, particularly Ruby. I think it’s very important that when you’re looking for a fresh solution to a problem, that you look outside your comfort zone.