DSLs: first, make them easy to read

Yesterday, I went to a presentation of Groovy at Paris JUG by Guillaume Laforge. One of his points was that Groovy is well-suited for designing DSLs – Domain Specific Languages. I think he said something along the lines of “with just a few commas here and there, you can get business-facing people to write the business rules themselves”.

Well, I disagree with that. While I am sure that some of these business guys are interested enough to spend time learning the little quirks of the resulting DSL, I expect most not to bother with it. It would be totally better if, instead of starting with a language and its constraints, you could start with what the business guys would want, and then design the language. Which is of course no small feat, and might be feasible only with a lexer/parser-type tool.

However, I think that Groovy is well adapted to what Martin Fowler recommends: first, make the DSL easy to read. From his recent post:

“You get most of the benefit of business facing DSLs by doing enough to allow business people to be able to read the rules. They can then review them for accuracy, talk about them with the developers and draft changes for developers to implement properly. Getting DSLs to be business readable is far less effort than business writable, but yields most of the benefits.”

The commas and other details are OK when reading a DSL, even for non-programmer people. This seems to be like a very pragmatic, valid approach.

In truth, this was visible in one of the examples he gave involving a health organization, fortunately documented on Guillaume’s blog:. Here is how it looked like (excerpt from this post):

regimen.take drug: CQ, qty: 2, at: 0.h

Easy to write for a developer. Easy to read for a business person.