Home > Software Development > Alternatives to Domain Specific Languages

Alternatives to Domain Specific Languages

April 27th, 2011 Leave a comment Go to comments

I have been reading Martin Fowler’s book Domain-Specific Language during last two months. Now I am not fully done with the book but have a good idea because the rest of the book is about individual DSL patterns, which I think are better read when used.

I got two key points from the book. One is that the key to DSL is semantic model (“The semantics of a program is what it means – that is, what it does when it executes”). You can implement semantic model as APIs/frameworks in system languages like Java. If you are confused by the question, “what is the difference between DSL and normal code on top of high level APIs?” you are definitely not alone. In fact, quite some DSLs are built on top of same high level APIs as would in traditional programming languages. The semantic models embodied in APIs/frameworks are cornerstones no matter which approach you choose. Of course, DSLs normally have simpler syntaxes than general programming languages.

Time to learn how to "Google" and manage your VMware and clouds in a fast and secure


The second key point is that a DSL is meant more for domain experts to read than for programmers to code it. So the readability is a key motivator for adopting DSLs. Not in any time soon, if ever, shall we expect domain expert to write DSL code. It’s just like that everyone can read novels but only a few write them.

With these understandings, a DSL is really a thin layer that solves a small part of an overall domain related problem. The bigger part is the semantic model/APIs/frameworks which are needed no matter what. So there is not much choice other than which normal programming language you use.

For readability, however, there could be several different alternatives to DSLs other than general languages. Here are some I can think of, and you can add more in comments:

  • Information highlighting. Just pick up whatever important and makes sense to domain experts, therefore they can browse the code and capture important information easily. Technically, it’s not new at all – syntax highlighting has been used in many IDEs and newer editors like vim; search engines highlight keywords in cached search pages. Here you don’t necessarily highlight language keywords, but important information like key string values, important API calls, etc.
  • Information hiding. With key information being highlighted, the rest code could still be a distraction. A naturally further step is to hide them totally or partially like wrapping them into smaller section. User can control what and at what level the code are displayed.
  • Configuration. It’s for sure much less powerful than a DSL, but may be good enough for simple cases.
  • Scripting languages. You can potentially improve readability using languages like Jython. Languages like Ruby gives you power to build DSLs.

To design these viewers, you need to understand and determine what information is important and what is not. It may require similar level of thinking as designing a DSL but waived the work for code generators or parsers.

With these specialized viewers, there may be less demand for DSLs. Having said that, I think almost everything has its place in this world; so do DSLs. What do you think?

  1. April 27th, 2011 at 09:04 | #1

    With Reflex’s Virtualization DSL that you mentioned here http://www.doublecloud.org/2010/02/vql-a-domain-specific-language-for-virtualization/ we are working hard to provide a UI that allows the domain expert to create as well as read the language. This, as you observe, is a delicate balance between functionality and readability. For the programmers, we allow the wrapping of VQL in Python as well as surface it over a web SOAP API. As using VQL programatically is far less complex than raw API (e.g. VI API to many end points) programming.

    Because of this SOAP API access to VQL we now have customers that were formerly writing direct to VI JAVA using Reflex and VQL as middleware interfaces into their virtual infrastructure.

  2. April 27th, 2011 at 12:31 | #2

    Hi Mike,

    You guys have done a great job in packaging VI Java API into a DSL. Any plan to open source it?


  1. No trackbacks yet.