Why do we have domain specific languages? They are supposed to make our lives easier for a specific task. SQL is the classic example of this, but XPath and other DSL's exist. SQL does an excellent job of doing what it was designed to do, support database access. Or does it?
SQL began life without and If statement, without assignment statements (:=) and variables but PL/SQL and T/SQL added them to make it useful. SQL has changed its spec 6 times since 1986. To include new features that people thought it should do. Still this is not enough.
I think the concept of a DSL has a a fundamental flaw. They can't move with business requirements and as such they need access to a broader language. This almost defeats the entire purpose of them.
The solution going on around the database world is to replace or integrate the DSL (SQL) with broad languages.(Oracle and SQL Server now support .net assemblies). The other solution is to add the useful features of the DSL into the non DSL (LINQ kind of adds SQL to .net). The point is SQL as the most well known DSL has failed to accommodate the business requirements of the developers world. And yet it is hugely popular and very useful.
The wikipedia entry for domain specific languages makes a good comment. "A domain-specific language is somewhere between a tiny programming language and a scripting language, and is often used in a way analogous to a programming library." And herein lies some of the problems with DLS's.
- DSL's are not libraries. They are not easily extensible. You can add to a library pretty easily. It's nigh on impossible for me to extend Oracle PL/SQL. The only people who can extend PL/SQL are Oracle and they move like a glacier. (Does this mean they are speeding up of late with global warming? ;) )
- DSL's by definition are limited in scope and usually dont' have access to the entire operating system. This means they usually don't cover all of the area's that people want to use them for.
This is a big problem for the developer. Initially you get a problem and let's say you solve it with a DSL, like SQL. It seems a a good solution, the language is designed for the job, its all a neat fit. But inevitably business requirements change and code needs to be refactored. But its a change thats not really in the fundamental design of the DSL, (ie you want to do some maths on data retrieved from a database). You oughta turf the DSL and go with a more flexible solution but you can't. Time and effort has already been invested, there is no time, the impact would not be this one area of the code but would affect other areas of the system. You are forced politically to go with the existing solution and do some kind of work around. The code ends up as a bit of spaghetti as a result and maintainability suffers. This goes on for a while and eventually the entire system becomes a rigid, impossible to morph system prone to bugs and errors due to the enormous complexity.
The problem here was not the change of the system, that happens all the time, the problem was the choice of a DSL.
It is hard to refactor SQL and as far as I know you can't unit test SQL. While functions are supported, classes aren't and using maths libraries in SQL is way out there.
Part of the problem lies in that SQL does not have access to a broad language like C#. LINQ is an attempt to solve this. This traditional boundary of DSL's not having access to the full operating system (which is by design) is a fatal flaw.
So my thought is to be warned when you choose a DSL that will not have access to a broad language. Ask yourself will it work in the longer haul? Can you break out of it to do non DSL specific things? And do this before you are wedded to the code base it will create. They have good bits but they are all flawed. In the end I now try and only use DSL's that have access to a broad language if I reasonably can (note the use of reasonably). Still I like the fundamental structure of something like SQL.