+972 52-548-6969
Graphical Domain Specific Languages
Another form of DSL is the graphical domain specific language.
What do I mean by that? I am talking a DSL that is not textual, but rather uses shapes and lines in order to express intent.
A good example would be UML. That is a DSL for describing software systems. In fact, quite a lot of money and effort has been devoted to making UML the One True Model, from which you can generate the rest of the application.
There has been also a lot of effort invested in making it possible to write your own graphical DSL. Microsoft has the Visual Studio DSL Tools, which is a framework that allows you to build tools similar to the class designer and generate code off of them.
Existing examples of Graphical DSL that comes to mind are:
· UML
· BizTalk
· Sql Server Integration Services
· Workflow Foundation
I don’t like graphical DSL. To be rather more exact, I simply love graphical DSL for documentation, but I find that they make a rather poor job when it comes to actual development.
I have some experience with all of the above, and I can say confidently that they all share common problems, and that those are inherit to the graphical DSL model.
For a start, any problem of any real complexity would be very hard to build using a graphical DSL. Just arranging all the shapes in a way that you can browse them easily takes significant bits of time, and then you get to the issue of actually understanding what this thing does.
The whole point of a graphical DSL is to hide information that you don’t want to see, to let you see “big picture”. All of which means that you can’t really see the whole at the same time, and this leads to a lot of time spent jumping between various elements on the DSL surface, trying to gather all the required data.
And then there are UI issues that are important. How do I do a search & replace operation in a graphical DSL? How can I just look for something? And, of course, there is a reason why mouse driven development is not a good idea, if only for your wrist.
Beyond that, there are serious issues with how do you make a reasonable diff between two versions. No, reading XML files diff (assuming they are even diffable) don’t work, you need some way to express diffs in a graphical way, and so far I haven’t seen any good way to do that.
From an implementation perspective, there are other issues that you need to consider. In a graphical DSL, the need to express things visually is pretty important, so we need to have some conventions about what shapes and connections we have. The actual what and how will depend on the actual language that you are trying to implement.
If you haven’t guessed so far, I am not a fan of graphical DSL. Not for programming, at least, it is a valuable tool for documentation and design, but quite a few people are pushing it too hard.
Comments
How would you feel about a graphical DSL you designed yourself?
Now, my guess is you would never choose that as a first option (or second or third, etc.).
But one thing I've been thinking about in something I'm working on is using the VS 2008 shell combined with GAT/GAX to implement a very domain-specific 'framework'.
Now, I currently have neither the time nor the skill to pull this off, but I can see the value in being able to create something like this, where I am the one who can design how the graphical DSL would work, and so would (in theory, see disclaimer about time/skill) be able to control the output in a rigorous way.
Not that they are the exact same thing, but this area is like code generation. I've read endlessly about how bad code generation is, yet I've been using it for so long, and loved it, that I've wondered what was wrong with me about it (not really, but you get the point). Then, I realized that since I design the code generator, I have the confidence in its outputs because if I don't like it, I can change it.
jdn
Jdn,
Most major issue with graphical DSL, how do I diff and merge between versions?
How do I do a code review?
How do I search for certain string? How do I change a setting?
How do I refactor?
Those are huge problems for graphical DSL. The best one that I know of is Active Writer, and even then, I am biased against it because of the above mentioned issues.
Can you define what you want in a more precise manner?
Another problem with graphical DSLs is that they are visually verbose, but contain a paucity of data per unit of screen area. (i.e. It takes a lot of screen real estate to convey even the simplest concepts.) Take a look at a reasonably complicated BizTalk orchestration that fills an entire screen, but is still legible. In my experience, the screen's worth of orchestration translates into a for-loop, an if statement or two, and some naive error handling. A textual DSL could express the same intent in a few lines of DSL code leaving plenty of room for comments or more code. If you've got a good textual DSL, you can always write a graphical view of that DSL for documentation purposes, but the converse isn't necessarily (or typically) true.
I do not use DSLs that are purely graphical. But talking about documentation, I think it is very useful to have a graphical representation for some DSLs that is synchronized with (or generated from) the DSL itself.
For example, any workflows or dataflows (think Rhino ETL) are much easier to see at a glance on visual surface. Editing them on visual surface is also an option, but not a requirement.
The problem with textual view at the flow is that you are limited with one dimension -- but it does not always make sense to order source code by the flow timeline (if you have branches, such ordering is obviously not possible). In the visual you can have any ordering.
Overall, my feeling is that the great visualization is priceless if it does not robs me of ability to see the internals and does not try to create some mess of it.
Comment preview