Hosting Domain Specific Languages

I’ve just discovered today that Microsoft are only going to allow languages created with the DSL to be hosting within Visual Studio. I’m very disapointed by this news. The general push behind DSL is to encourage Software Factories and generally improve the practices used to create applications. The big trick I believe they’ve missed is that there are many applications that allow the user to customise their experience. Why should we ignore our application users and let them live outside of good software development practices? Even if you only consider such users as casual developers, getting people involved in good practices at any level can only be a good thing. There are many professional developers who have started life customising existing applications and, "getting them while they’re young" approach would seem a good idea. Don’t get me wrong, Microsoft Tools division has as much right to make money as anyone at Microsoft, but I think forcing DSLs to be created only in Visual Studio and then allowing them to be deployed and used freely would be a much better strategy. Even the Windows Workflow Foundation (or Workflow Foundation as they prefer) team have produced in essence a DSL for workflows which they allow to be hosted without Visual Studio so why not custom DSLs? Very disapointed.

Domain Specific Languages vs. UML

I’ve been keeping a sceptical eye on Software Factories and Model Driven Architecture (MDA) for some time so I was very interested to see a Domain Specific Language (DSL) API spring up in the latest drop of Visual Studio. I thought I’d better do some reading around the area to try and understand its goals. During my "travels" around the web I came across the following blog, Jack Greenfield’s Blog. Amongst other things it talks about an on going debate about using UML for MDA (and for Software Factories in general) vs. DSL. Now all the arguments for and against each one are all very interesting and exactly the sort of thing to get real-ale drinking software architectures in a bother, however for me there is one clear advantage for DSL…the average user. I don’t think I’d be burnt at the stake for suggesting that as good as UML is, the majority of people successfully cherry pick UML in order to describe/document their solution, very few would take it through every stage. Again I don’t really want to get into a debate about why people don’t use UML I just want to state that, rightly or wrongly, people don’t believe it is some kind of silver bullet/fits-all language. This brings me to my point (hurray), so far I’ve been talking about people in the software business what hope have we in convincing Joe public to use UML? As much as we like to make our solutions generic it often becomes more complicated for the average user. Did the average user welcome the fact that they could use VBA in Word and Excel? Sure the developers (and hackers) did but did the average user? I’d suggest not. What the user wants is something that talks in the language they understand. So for Word they’d probably want something that talks about text changes, font formatting, picture adjustments, spelling, etc. For Excel formulas, statistics, graphs, etc. Now sure there is some common ground that could be exploited but basically the domains are different. So assuming that I’ve established that the user wants domain specific tools how to best address that? This is where the arguments of DSL vs. UML step in. But wait, if we can’t convince the software development community about UML how on Earth are we going to convince Joe public, surely it will be better to provide specialised DSL for the users problem domain? "But they’d have to learn a new tool/language for every one", I hear you cry. True, partly. This brings me back the cherry picking of UML. Personally I feel UML is too verbose and clumsy to be used "correctly", but what it is great at is conveying ideas and requirements without necessarily concretely specifying them. E.g. I can draw an interaction diagram describing how to spell check and save a Word document, but I wouldn’t feel it necessary to write out a full class specification for a Word document so I could include it in the interaction. I realise this might shock the purists but I’d argue that the real goal of UML is to successfully convey the requirements and to describe the solution. I believe it is successful at this because the concepts of shapes and flow are pretty easy to understand even without formal training. Therefore I believe that providing you implement your DSL using fairly simple concepts but still talk in the context of the domain you can take the reusable parts of UML and still provide the average user with a toolset they can understand.