f3yourmind

I had quick DSL appropriateness argument last week for someone that was objecting about us implementing a DSL for some small part of the domain.

The argument: “Business users will never write code”.

My response: “But business users will read code”.

And to test the argument, I later emailed one of the business users with a small snippet of the DSL that we were crafting and simply said in the email: “Please check the following configurations for the client…”.

His response: “You incorrectly configured the final_costing_policy.  It should be …”

In the large, the DSLs that you create are going to be read by a larger audience than just developers.  So, like all good code, this DSL code should be highly readable, but not all of your audience needs to know it’s syntax in detail.  You create a DSL to make your life, the developer, easier.  Getting business users to understand what you are doing is part of making your life easier.  Anyway, is it not about ubiquitous language and vocabulary?  You can’t get closer to the domain than revealing data and behavior with a DSL, can you!?

I’ve been doing some internal DSL coaching recently, and my coaching-partner and I have been working BDD/TDD style.  It turned out to be quite a nice experience overall.  We started with a Cucumber based feature that described the behavior of a typical DSL script and we drove it down into rpsec where we tested each little part of the script.  In the end, I achieved what I set out: the person I was coaching grokked the whole “code is data” idea behind DSLs.

Then I started thinking about what it takes to coach external DSLs.  I got really scared – parsers, generators, abstract syntax trees.  Those were things that most people wanted to forget about the day after they wrote the exam for that horrible semester course in university.  What makes it worse is that I never did that in university – I did Electronic Engineering and we spent our coding time figuring out how to do Fast Fourier Transforms on digital signals.

But when I look at the progress that is being made in language workbenches to help us create DSLs, then I reckon we should dust off those books and start paying attention again.  Some of these language workbenches still leverage a host language such as Java or C#, but the act of using a structural editor that edits the AST directly is strangely weird.  But, some refactorings are just not a problem anymore.  For example, if you are changing the node on a tree, then all the references to that node are automatically aware of it.  Compare that to a text editor where you need refactoring wizardry in the tools to make sure all references are updated neatly.

I think that language workbenches may be a great tool for coaching DSLs because the things that made your head spin during that lex and yacc week, are made a whole lot simpler.  You can focus on designing the language and walk into ASTs with less fear.  But, be warned — language design is not easy, and you still need to know about ASTs and parsers and generators.  In fact, just write a parser and a generator and it will be a learning experience that goes beyond DSLs.  Better still, do it BDD/TDD style.

The relevancy of language oriented programming is just going to continually increase.  Those previously “irrelevant” courses are important again.  Watch out, the gap just got wider.