What are DSLs good for?
A few posts on DSLs and Ruby have popped up recently. I find myself agreeing somewhat with this contribution from Maurice Codik:
In the long run, I don’t think the main value from DSLs will come from allowing non-techincal users to encode business rules, but instead in helping programmers make their programs more DRY.
To my mind there are two big wins from DSLs, and almost everything else is wishful thinking. The first is the ability to hide implementation details – often called encapsulation – and to express exact intentions.
Let’s take one of the poster children of DSLs: SQL. A typical, but basic, SQL statement could be SELECT people.name,company.name FROM people,companies WHERE people.company_id=companies.id AND people.role=”manager”;
Nothing too taxing there but a host of implementation detail has been hidden from me – I don’t care how the data is stored – whether on disk or in memory – I don’t have to describe to the database how to present the data, or how to perform the set arithmetic or how to use its indices to improve performance.
– Even so, some implementation details have leaked through – what’s with all this id=id business? Wouldn’t it be more expressive if I wrote something like: SELECT people.name, RELATED company.name WHERE people.role=”manager”. We can dream. –
DSLs are the epitome of the search for implementation hiding and clear expression of intention over process – some people characterize it as ‘declarative’ over ‘imperative’ coding.
Be warned, lunatics will try to convince you that you still need to know how the database works in order to use it effectively – that encapsulation is pointless and even dangerous. To these people, I’d point out facetiously that my Grandmother thinks electricity is a kind of spooky magic, but she still knows how to switch on the kettle.
The second big win is related to encapsulation and to my mind is even more important. DSLs remove an impedence mismatch between business and code by offering a commonly understood and comparable expression of intention. What I mean by that is that the closer the code is to expressing the intentions of the business, the more easily it can become a shared resource that both business and development can draw on. In fact, I’d go further and say that it helps break down the distinction between business and development – as an aside, can you imagine anyone suggesting a distinction should exist between accountancy, another specialised art, and business?
Let me take that illustration further: you have to learn a certain language to understand a business’ profit and loss report – what are accruals, expenses, gross margin, net margin, etc. By learning that language you can understand the business more deeply. No-one in a large business – no-one in their right mind, anyway – would ask a developer, a marketeer, a salesman to create the profit and loss reports – that’s an accountant’s job. But part of their job, if they’ve done it right, is to make that picture of the business something that everyone who invests, works in, or has some interest in the company understandable.
DSLs allow developers to communicate the way a business process is modelled in code to a non-developer. And, this requirement to communicate through your work is something that has been sadly lacking in most company development teams I’ve had experience of, but accepted in other departments – sales, finance, marketing, etc.
DSLs give us a chance to work towards it – but don’t expect that you’ll get effective results by claiming ‘everyone is now a developer!’. It makes as much sense as saying ‘anyone can now file our annual tax return’, and it misses the two big DSL wins – implementation hiding and communication.
I'm Ben Griffiths: