Domain-specific languages, or DSLs, received a fair amount of attention lately. A mini-language tailored to a specific task or problem domain can increase developer productivity, and result in higher quality code. In a pair of blog posts, I'm coming down with a serious case of the DSLs! and Behind the scenes of the planning DSL, Anders Norås explains how to define a simple domain-specific language in C#:

Writing DSLs is a little different from the regular object oriented programming style. You might have noticed that the [example] class has a verb for its name rather than the usual noun. This allows us to have a natural starting point for writing out the "sentence" explaining our intention...

Rather than returning an instance of the type we want to create, the operations on the [example] class return descriptors which we will use to collect the information needed to create these types. These descriptor types is the backbone of the DSL. The DSL is basically a fluent interface. With some exceptions, every method or property in the fluent interface returns an instance of the class it is defined on allowing operations to be chained together.

It is more difficult to write a fluent interface than a plain old API, and I agree with Martin [Fowler] that it takes quite a lot of thought to get the grammar right. I've found that it is best to start with a test case and just write the "sentences" before starting to implement the actual language. Not only does this help you to come up with a good language, it also helps create all of the classes, methods and properties that are needed...

What do you think are the most important principles in coming up with a good DSL?