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.

It is true that there is a fine line between normal readable code and a DSL…
That said, I have never really tried to go as far as getting approval from business types. I’m willing to give the benefit of doubt for the moment.