Domain Specific Language (DSL) is a technique for crafting a special-purpose languages to create solutions within a specific and well-defined problem space.  The potential is immense.  They may be a little over-hyped (in some circles), and I think we’re still a ways from business analysts writing their own systems…

Nevertheless, I assert that DSLs are important and will increase in popularity and utility as the tooling improves to allow “DSLs for the masses”.  SQL, HTML, XAML, UI and Process design surfaces.  These are all examples of DSLs and all revolutionary in power and productivity.

I’m of course not advocating that everyone build a new DSL for every project, but when there are “product families” which share a problem space, the power of DSLs is undeniable.

The power of DSLs comes from working with high level code elements that are “abstract” but not “imprecise”.  It’s like one of these trade-off triangles.  Everybody knows the scope-staff-schedule triangle.  You can hold two fixed, but at least one must move.

With DSLs, the triangle is abstraction-precision-domainScope.  If the domain is huge or unbounded, you have to choose between abstraction and precision.  This really limits the power of the abstraction, because it can’t be fully precise and is therefore not “code” – not executable even in theory [1].  However, if you limit the scope of the domain, you can raise the level of abstraction without losing precision.  This - in a nutshell - is the “magic” of DSLs.

[1] This is closely related to the Platform Independent Model (PIM) fallacy, but that is another tale.