Wednesday, September 23, 2009

Talking about DSL

Originally Published on March 11th, 2008 @ 07:30:36 pm

Back after several months!
It is incredible the amount of work a change in your job position brings in its tail!

But for now, let's talk about the title.

I was recently reading a great blog from Michael Stal (which I'm adding to the interesting blog's section). The latest post is referring to Domain Specific Languages (DSL).

It is interesting, the list of examples of what can be considered a DSL. Being as attached to formality as I’m, my take is on the D and the L of the acronym.

First, it should be Domain driven. That means this “tool” will work inside a domain scope, referring to the elements that make sense inside that domain. If used as a communicator (as I will explain later) the reader may have knowledge in that domain. For instance, if you explain your solution to a manager in terms of resources, time and cost.

The second is the language constraint. That is, DSL is a language: a grammar and a vocabulary (plus maybe rules to expand that vocabulary). The language is used to describe things in sentences. Those things could be the problem or even the solution. That description can be read, understood and even executed.

I recall a very old issue of Dr. Dobbs that talked about mini-languages (or was it micro-languages?) that were script languages in essence. An example was the MS Excel macro language of that time. Specifically, the macro language had the typical constructions for conditions and loops, but the vocabulary was focused on cells, rows and columns, selections and texts, formulas and styles. The Domain was very explicit. It also mentioned another languages, some derived from C. those where subsets of the C language with some tweaks. Were those DSLs too?

Probably no one will say C or Java is not a language, so we have the L from the DSL combo. Now, which is the Domain for a language like Java or C? Or even for those little subsets of C? I guess we can find one, very broad, but it will not fit into the idea of specifying a particular domain and focusing on it. Thus, my bet is no, they are not DSL.

Now, let’s go a little further: people use DSL all the time! I’ve known programmers everywhere that use encodings in strings. Have you done that? A string that contains a list of values separated by a “separator” (colon?) and the first value is the code of the operations, the other values means something and such? Have you hear of the interpreter pattern? Those are DLS in a String! Micro DSLs, something executable and some other time just to display.

Wait, here is another point: Does this DSL need to be executed? It may not! Actually, a language is to describe things. ADL (to describe architectures) will no be executable (probably). So they may be just to describe, to be “Human-Interpreted” languages (it may also be machine readable to validate it, but that may not be a requirement). What about a VDL (View Description Language ) that will allow the architects to describe the viewpoint of a solution in a language in the stakeholder domain ? It may be graphical, but not required. It can be a simple subset of natural language. Let’s invent the DSD (Domain Specific Dictionary) as a glossary for the DSL vocabulary.

The example that just comes to my mind is Bool’s language. It has some symbols, but when you read them is sounds like natural language, but focused on logic! A AND B OR C IMPLIES D.


Reference: Talking about DSL

1 comment:

  1. Hi William,

    >> It is interesting, the list of examples of what can be considered a DSL. Being as attached to formality as I’m,...

    Yes, you've tried to formalise sotfware terminology before. I think it's the academic in you :)

    As for me, I learned long ago to accept most software terminology for what it is, pseudo science and marketing labels.

    DSL is a term coined and made popular by Martin Fowler. Any attempt to codify the term would do well to reference his original article:

    Like yourself, Martin is big on defining terms to describe different aspects of software development, and like yourself I believe he is well intentioned.

    Some how these good intentions tend to go awry :) I've seen people using (abusing) DSL's in an attempt to produce self documenting code. So common internal DSL techniques (see martin for a definition of internal DSL's) like returning yourself in response to a method call are used to define "fluent" interfaces to objects.

    The problem is that a DSL and a fluent interface is even harder to create and get right then a normal API, and the good ones are ones that have emerged over time rather then ones that were designed upfront. I'm currently working with some C# guys who have Ruby/Rails envy and see it fit to create Rails like DSL's at every opportunity in C#. The result? over verbose and non-fluent interfaces where you find yourself peaking at the implementation inorder to find out what is going on. What ever happened to good clean OO interfaces?

    So it looks as though much of Martins good intentions were in vein :) DSL's have become another buzz word and an ends in itself for some, rather then a means to an ends :)

    It brings to mind the saying that a little knowledge can be dangerous. How true :) I can feel my normal rant coming on about software developers needing hands-on mentorship and that they should serve an apprenticeship at the knee of a master craftsman before being given a license to go solo, but this is your blog :)

    I like contrasting my pragmatic commercial experience with your academic rigor. The two perspectives make a nice contrast. I hope you don't mind and that you find my ramblings useful.

    Best regards,