Neal Ford‘s talk about DSLs and how to create them in static and dynamic languages (Java and Groovy in this case) was very interesting because he clear up the fog around DSL’s a but, why they are great and when they help. Basically a DSL is “jargon”. It is compact code that allows you to express much more tightly what you want than any “general purpose” language (“one site fits all” actually makes everyone look ridiculous).
Remember that old OO promise to allow to mirror the world in a programming language, to allow to model the code after what the customer had in mind? Turns out, that OO was … nah, not lying … it was just overselling itself because customers don’t think in objects or models. They think jargon. And DSL’s allow you to make a compiler understand jargon. That’s even possible with Java even though “Java is like taking to a retard”: You always have to repeat yourself to make sure that the stupid compiler gets what you want (pun intended).
A DSL is not to be confused with an API. An API uses explicit context like “obj.setThis(…); obj.setThat(…);” etc. Here “obj” is the context and “setXyz()” is not meaningful without knowing the object we’re talking about here. A DSL, on the other hand, is all about context and context is implicit. It goes “obj.should(…).allow(…).this(…)”. An example is hamcrest: “assertThat(theBiscuit, is(myBiscuit));” Reads fluently, compact code, and it’s obvious that “is(myBiscuit)” should be compared to “theBiscuit” in some way.
The handouts of his presentation are available from his homepage but without his witty remarks. A pity but still worth to check out if you want to see just how far you can push Java to get code that your customer might understand.