Tag: DSL

DSL classification: a quick Domain Specific Language dictionary

by Marco Brambilla, posted in Uncategorized

I wrote a post some time ago on the classification of DSLs, that presented some dimensions of DSLs:

  • Focus of a DSL (vertical vs. horizontal)
  • Style of a DSL (declarative vs. imperative)
  • Notation of a DSL (graphical or textual)

But today (triggered by the discussions at Code Generation) I realized I overlooked a few obvious classification dimensions that are worth mentioning:

Internal DSL vs. External DSL
As defined by Marting Fowler in his blog, External DSLs have their own custom syntax, you can write a full parser to process them, and you write self-standing, independent models/programs using them
Internal DSLs instead consist in using a host language to give the host language the feel of a particular domain or objective, either by embedding pieces of a DSL in the host language or by providing abstractions, structures or functions upon it.

Interpreted DSL vs. compiled DSL 
(aka., model interpretation vs. code generation)
 This dimension has triggered a long debate in the MDD community. Model interpretation consists in reading and executing the DSL script at run-time one statement at a time, exactly as programming languages interpreters do.
Code generation instead consists into applying a complete model-to-text (M2T) transformation at deployment time, thus producing an executable application, as compilers do for programming languages.

If you want, you can suggest further classification dimensions you deem relevant for DSLs, your contributions is really appreciated.

To keep updated on my activities you can subscribe to the RSS feed of my blog or follow my twitter account (@MarcoBrambi).

Highlights from LWC 2011: Language Workbench Competition 2011 (co-located with Code Generation 2011)

by Marco Brambilla, posted in Uncategorized

Language Workbenches, as defined originally by Martin Fowler, are tools aiming to cope with DSL creation and code generation to increase the level of abstraction of software development [credit to Pedro J. Molina for the reference].The Language Workbench Competition at Code Generation 2011 aimed at gathering and comparing the features of different workbenches available today, through a small challenge based on a set of requirements.
Then, the challenge was summarized in the Code Generation main event. Here is a quick writeup of the presentations of two good representatives of the presented tools, not focusing on the performance within the challenge but more oriented to giving an overview to the field (especially for novices).
The complete list of submitters includes:

Among the above, I could only attend the summary of the two contributions from OOMEGA and Intentional:

OOMEGA (www.xenium.de, http://www.oomega.net), presented by Christian Merenda
Oomega is based on Eclipse, supports ATL for M2M transformations and Xpand for M2T transformations.
It’s based on the theoretical graph-based Edge Algebra
Upon it, there is M2L as a metamodeling language.
Oomega is the tool that implements it.
It works with continuous and incremental changes between the graphical and textual representation of the models.
The tool is showcasing 5 interrelated DSLs.

Intentional Domain Workbench (http://intentsoft.com/), presented by Mats Helander
It’s a projectional editor, not a text-based tool (i.e., based on a parser). It’s instead based on a tree representation of the languages, which is then reshaped based on projections.
References are not name-based but node-based instead. Every node has an ID and you reference them. So, if you change a name of a class, you get automatic updates in the referenced objects.
The specification is based on an extension of C#, extended with some DSLs.
You can get textual or graphical projections, and also document-like projections; you can mix different notations.
This allows involvement of non-technical, business users too
You also get for free code-completion-like features.
The technical paper presenting the solution to the challenge is available here.

To keep updated on my activities you can subscribe to the RSS feed of my blog or follow my twitter account (@MarcoBrambi).

Building DSLs: who, how and when

by Marco Brambilla, posted in Uncategorized

Due to a recent discussion I had to spend some time thinking on who should build a DSL (Domain Specific Language) and why, as opposed to who should use it.

Let’s start from some basic assumptions:

  1. Good abstractions must be intuitive and make life easier, not harder.
  2. DSLs are a must-have for most application scenarios (I’m not thinking only to software)
  3. Finding the right abstractions for defining a DSL is hard and time consuming
  4. Domain experts basically care about maximizing their productivity in working in their domain, but do not probably willing to spend huge amount of time defining methods and tools for that.

That’s why good DSLs do not come out of the blue everyday. And despite I can be a fan of language design and open DSLs, I think this is fine as it is.
The final goal of MDSD (Model Driven Software Development) is not to make every developer a language designer. The goal is to have good DSL designers that build good DSLs for the right audience.
Our experience with DSL visual languages in the Web context (WebML, see http://www.webml.org) is that it took years (together with tens of industrial experiences and thousands of users) to refine and polish a good language. That’s why I’m saying that a process like this can’t be in charge of any developer or designer.

Then, obviously a good DSL should be open for extensions and closed for modifications (ahh, the good old open-close principle!).

Finally, about tools: good tools must go with good languages. And I think that domain specific architectures (shall we call them DSAs?) should pair DSLs. As we say that one language does not fit all needs, I would say that an architecture may not fit all languages.
This could give you the impression I’m somewhat skeptical with respect to generic model-based tool/editor generators (and that’s actually true). Tools, design interfaces and publishing architectures should be tailored to the users, otherwise we fall back to the problems that should have been solved by abstraction and simplicity of the DSLs.

Some thoughts on DSLs (Domain Specific Languages)

by Marco Brambilla, posted in Uncategorized

Domain-Specific Languages (DSLs) are design and/or development languages that are designed to address the needs of a specific application domain. DSLs are particularly useful because they are tailored to the requirements of the domain, both in terms of semantics and expressive power (and thus do not enforce end users to study more comprehensive general-purpose languages) and of notation and syntax (and thus provide appropriate abstractions and primitives based on the domain).
I wish to highlight a few classifications of these languages, namely the dimensions of focus, style and notation. 

The focus of a DSL can be either vertical or horizontal.
Vertical DSLs aim at a specific industry or field. Examples of vertical DSLs may include: configuration lan-guages for home automation systems, modeling languages for biological experiments, analysis languages for financial applications, and so on.
Horizontal DSLs have a broader applicability and their technical and broad nature allows for concepts that apply across a large group of applications. Examples of horizontal DSLs include SQL, Flex , WebML , and many others.

The style of a DSL can be either declarative or imperative.
Declarative DSLs adopt a specification paradigm that expresses the logic of a computation without describing its control flow. In other words, the language defines what the program should accomplish, rather than describing how to accomplishing it. A typical example of declarative definition is the one of service choreography.
Imperative DSLs instead specifically require defining an executable algorithm that states the steps and control flow that needs to be followed to successfully complete a job. A typical example of declarative definition is the one of service orchestration.

The notation of a DSL can be either graphical or textual.
The graphical DSLs (al-so known as Domain Specific Modeling Languages, DSML) imply that the outcomes of the development are visual models and the development primitives are graphical items such as blocks, arrows and edges, containers, symbols, and so on.
The textual DSLs comprise several categories, including XML-based notations, structured text notations, textual configuration files, and so on.

Despite the various experiences in DSL design and application, there is no general assessment on the preferences of the developers for one or the other kind of language. However, typically languages oriented to the end users tend to be more visual and declarative, while the ones for developers are often textual and imperative.
This post is not meant to be a thorough discussion on DSLs though. For more info you can have a look at:

Other thoughts in this regard will be soon available within a chapter of the second Search Computing book, to be published as Springer LNCS volume in March / April 2011.