Stuart Kent - Building developer tools at Microsoft - @sjhkent
Pedro Molina has blogged about his experience at the code generation conference in Cambridge. Pedro was one of the folks with whom I had some great discussions, and his commentary on the conference is well worth reading.
The term Domain Specific Language (DSL) is a popular buzz-word at the moment. If you look at wikipedia you’ll see the following definition:
“In software development, a domain-specific language (DSL) is a programming language or specification language dedicated to a particular problem domain, a particular problem representation technique, and/or a particular solution technique. The concept isn't new—special-purpose programming languages and all kinds of modeling/specification languages have always existed, but the term has become more popular due to the rise of domain-specific modeling. The opposite is: a general-purpose programming language, such as C or Java, or a general-purpose modeling language such as the UML.”
“In software development, a domain-specific language (DSL) is a programming language or specification language dedicated to a particular problem domain, a particular problem representation technique, and/or a particular solution technique. The concept isn't new—special-purpose programming languages and all kinds of modeling/specification languages have always existed, but the term has become more popular due to the rise of domain-specific modeling.
The opposite is:
The problem I have with this definition is that it’s hard to draw the boundary between what is general purpose and what is domain specific. Instead, I prefer to think of a language having different dimensions, and to categorize a language we need to place it on each of the dimensions relative to other languages. This leads to a much more fluid categorization system, but makes it easier to identify the similarities and differences between languages. Below is a diagram I produced recently for a talk showing three dimensions. I think there are more, but these three seem quite important. I put some examples on the diagram to illustrate.
And as a tool platform vendor, I’d like to provide facilities for creating and using languages in as many points in that 3-dimensional (though probably should be n-dimensional) space as possible. I also want to provide ways of moving between languages at different points in the space.
What might other dimensions be? Martin Fowler makes the further distinction between internal and external DSL, so perhaps that might be another, though in that case I might concede that the dimension is binary: external xor internal, and no points between. Another might be formal/informal dimension.
Now I’m back from the conference, here’s an update on my first report.
Some highlights for me during the rest of the conference were:
[Added on 23rd June 2009]
I missed another highlight. There was a demo of Jetbrains Meta-Programming System (MPS). Although perhaps not for the masses, I thought this was conceptually very clean and nicely done. Great interactive session as well.
I see that Jean-Marc has just posted another sample on the DSL Tools Code Gallery landing page, this time about the new IMS Locks capability. This allows you to make some parts of your models read-only, which is good for situations where some users (say an architect) are allowed to make changes to some aspects of the model (say the core architecture components), and other users (say developers) are only allowed to make changes to other aspects (say the properties specifically focused on driving the code generators). As author of the DSL you have complete control in the locking policy used. More details in Jean-Marc’s post.
I’m at the Code Generation 2009 conference in Cambridge, which started yesterday.
Numbers are a little down on last year, but not much. Attendance is mostly from industry, with some academics. As usual it’s stuffed full of people with tons of experience in building code generators and languages to drive them.
I gave a talk yesterday which placed model driven development and code generation in the wider context of what I called the design cycle (see image below). Perhaps I’ll write it up as an article on this blog someday. I also illustrated this with a demo of some of the features of Visual Studio 2010, including the new tools for visualizing existing code through graphs.
Interesting panel yesterday on migrating to model driven development. There is real, concrete data out there which demonstrates the productivity benefits of an MDD approach. Why is it, then, that everyone isn’t doing it? Lots of discussion, with the top reason being social and cultural issues. It was also suggested that tooling isn’t good enough for broad use.
I’m sitting in the keynote which has an interesting format: the two invited keynote speakers (Markus Völter and Steven Kelly) decided to join forces and give a joint talk spanning the two sessions. I like it, especially when the speakers argue (e.g. textual DSLs, which Markus favors, versus graphical DSLs, which Steven favors; actually they concluded that a platform which integrates and supports both would be best).
Jean-Marc has just posted a ModelBus Adapters project template on the Visual Studio Gallery. This template makes it easy to a modelbus adapter and adapter manager to your own DSL, which exposes your DSL for reference and access from other DSLs. This compliments the sample recently posted, as described in my last post.
One of the most common asks from customers of the DSL Tools has been support for integrating models and designers, that is the ability to have models of the same or different DSL cross-reference one another, and the ability to write simple code that exploits these cross-references to implement interesting interactions between designers.
In VS2010 we’re providing this support which can now be previewed in VS2010 Beta1 release. Jean-Marc has just posted a sample (StateMachineOverModelBus.zip, documentation) that illustrates how the modelbus can be used to achieve the behaviors described above, and I’ve just posted a short video demonstrating the behaviors and giving a quick insight into what you need to do to realize them in your own designers.
Details on how you can provide feedback can be found on our the DSL Tools Code Gallery landing page. Or by all means provide feedback on this blog.