(Back to software development, at least until Game 4 tonight...)
Microsoft has announced a framework and tools for creating Domain Specific Languages in Visual Studio Team System. Your very own DSL will be powered by the same modeling engine that powers the “Whitehorse” Distributed Systems Designer.
Whether this will be a big or small deal hinges on two questions:
- To be useful in software development, do the majority of diagram types need to share a large amount of common semantics?;
- Is it a large or small set of software development tasks that can be adequately represented in diagrams?
UML proponents argue for the first -- that one basically needs UML-level complexity/richness to create diagrams that are not just used for communication between people but that actively shape the system under development. This is obviously self-serving for those with an investment in the UML process, but may be true nonetheless.
The second question is open. I'm a big fan of UML, but primarily for communicating important subsets of the task in question: “here are the key classes and their relations,” “here are the vital calls in this sequence of actions,” etc. Today's display technologies and graphical tools don't provide the information density that text does and the speed of manipulating a diagram is significantly less than making a comparable change in source code.
The tools announced today will obviously be used to implement various diagrams that are known today -- UML, E-Rs, BPMs, flowcharts no doubt. That's all well and good but won't fundamentally change anything. The key issue is whether the type of person who today might develop a complex library or language to express a domain (say... job-shop scheduling or customized-pricing rules) will find in these tools sufficient power to develop an alternate way of expressing the domain.