Is there any escape from Domain-specific Languages?
Unless you’ve been living on Mars for the last few months – like wot I have – then you can’t have failed to have heard that Microsoft are planning their long-awaited release of Visual Studio 2005. Along with a bunch of cool and useful additions to the suite, those clever chaps in the tools & technology group have come up with a little something they’re calling Domain-specific Languages. DSL’s are to third generation programming languages like Java and C++, what 3GL’s are to lower-level languages like Assembler.
The theory behind DSL’s is that, just as Assembler grouped together bunches of lower-level machine code into shorter, simpler instructions, and a language like C++ groups together bunches of Assembler code into even shorter, simpler instructions, DSL’s will provide a way to group together bunches of .NET code into a yet shorter, simpler visual programming language that will allow developers to put new applications together faster and at less cost.
DSL’s are a natural successor to reusable code libraries. Indeed, they are reusable code libraries – but captured in a way that makes them much easier to reuse. When you create your DSL, you also create a visual representation for it so that developers can plug elements together using a graphical editor, in much the same they do now with Windows user interfaces. But instead of dropping a button onto a form and having the code generated by the tool, they would now be able to drop a Customer or an Invoice into a business process and have the code generated for that.
On paper it all sounds great. I, for one, wouldn’t want to go back to punch cards, so I can see the attraction of raising the level of abstraction yet higher. But there might be a fly in the DSL ointment…
The “domain logic” of a 3GL hasn’t changed much in all the years since they were invented. Programming languages have variables, data types, modules, functions, if…else… statements and so on. I can write a program in Java now that I could have written in FORTRAN forty years ago. A program is a program (is a program).
Business logic is less stable. When I develop my banking DSL for Acme Investments Inc., and give it to their 200 C# developers to build end user applications out of, what happens when the business rules change? What happens when the Settlement Account business entity doesn’t have a one-to-one relationship with a Customer anymore?
To put it into perspective, think what might happen if the syntax of the Java programming language was revised every few months.
Perhaps Microsoft has an answer, and I’ve just missed it somehow. But I can’t help feeling that we’ve been here before…
Published: Friday, January 13, 2006
© 2012 All rights reserved. Reproduction in whole or in part without permission is prohibited.
Please see our copyright notice.
If you want to use any content you have seen on this site then
please request our media pack and
ask for details of our Content Licencing Service.