Wednesday, February 27, 2008

Domain Specific Languages

Domain specific languages are hot topics lately amongst the ALT.NET list serv.  DSL's are something that aren't necessarily something that all of us are thinking about every day, but they are definitely something that we use on a daily basis.  It's likely that if you working on a software project, that you've been working with at least one domain specific language.

So, what is a Domain Specific Language?  A DSL is a language that you work with or that you build that is tailored to solve a specific domain problem.  Some great examples that you probably use every day are Google query syntax, and MSBuild.  If you think about how you use these tools, you can see how they have developed a language that solves a specific domain problem.

You can usually classify domain specific languages into two areas.  Internal DSLs and External DSLs. 

Internal DSLs are languages that you create to use as a tool to help you develop your end product.  These languages are usually tied pretty closely to the underlying base language, resulting in an intermingling of base language constructs with your DSL.  Have you created objects that have conditionals and predicates for searching your entities?  If so, that's usually an example of an internal DSL.

The second kind is a language that you provide your users to use to do work.  You'll usually find these in rich reporting tools and also business rule engines that allow end users to write their own business rules.  These languages usually hide the underlying language completely, and provide extremely expressive and terse constructs that give the user an spoken language-like environment for doing work.

So what's the difference between a DSL and an API or a Framework?  I think the semantics are important.  There's a big difference between a facility and a dialect, and between a framework and a language.  When your recognize that what you are building is a language, you begin to design things differently.  As an example, you're perspective may shift from providing factories and service layers, to using expression builders.

Why do you care about recognizing when you're using DSL?  The reason it's important to recognize this distinction, is that the perspective you use during design changes drastically once you realize you're writing a language, and not an API.  Once you're designing from the right perspective, you'll find that you'll be providing a language that gives you and/or your user the ability to do extremely interesting things with your software.

What makes them difficult to use and implement?  There's usually more effort in designing a language than a framework or an API.  Where you can make technical decisions and assumptions in an API, you need to ensure fluidity and expressiveness in a DSL.  And with that expressiveness comes an infinite combinations of conditions, and an exponential number of test cases.

References

Domain-specific programming language
MFBliki: DomainSpecificLanguage