show all comments

DSM

DSM languages are more than frameworks

December 13, 2005 13:11:29 +0200 (EET)

Spotted in Claudio Perrone's Monologues

It is realistic to assume that experienced developers/architects who fully understand the domain and have been involved in the development of enterprise frameworks are the natural candidates for authoring well thought DSLs for an individual organization. On the other hand, there is a danger that such authors might treat DSLs exactly like class frameworks, without realizing that the forces at work are significantly different. ...
Using this tactic for DSLs would lead us to create “flexible” implementations of a language through the introduction of (superfluous) configuration/customization options to our models, without considering that every time we add an extra element, attribute or connection to a DSL we arguably make the language more difficult to use and, ironically, less adaptable.

Yep. As Claudio and I discussed earlier, it's all too easy to build your first modeling language at the same level of abstraction as the code you used to write, and therefore miss out on 90% of the benefits of DSM. As developers we're taught that making something more general -- expanding its range of application -- is a virtue. Even in building a framework, though, this can be taken to extremes. Anybody who has programmed with Windows file dialogs or used DirectX will be familiar with the problem of having to supply 17 parameters or do 10 steps to complete one simple action. On the issue of Humane vs. Minimalist interfaces, I side with Jeroen's basic conclusion: both minimalism and humaneness are virtues, so we want both. One way to get that is his suggestion of a humane interface wrapping a minimal implementation. Another is imply to strive for the most efficient balance: the Minimal Humane interface.

A DSM language aims to minimize the time needed to create the desired range of applications. That's a long way from the Minimalist argument: a minimalist won't bat an eyelid at the >300,000,000 calls to aList.get(aList.size -1) in Java programs. (If you don't believe my figure, go count them yourself :->). But just think of the extra time it took each time to write that rather than aList.last(): one is 24 characters, the other 12. With my typing, that's 10 seconds vs. 5 seconds, so a cost to the global economy of >500,000 man-hours. And how often does somebody make the mistake of aList.get(aList.size)? Even if it's only a one in a thousand mistake, that's still >300,000 bugs that have to be found and corrected.

Now tell me, what is the cost of creating an operation called last()? Probably all of 50 seconds, including documentation. And what is the cost to users in terms of learning another operation, and having to scan over it when looking for something else? Even my boldness doesn't stretch to estimating that! But surely, for a class as frequently used as Array/List, and for an operation as obvious as last, the cost of having that extra operation is offset by the saving in having simpler code?

That simplicity is a key factor in the increase in productivity with DSM. Unfortunately, there's no easy way to measure simplicity. 17 arguments for a file dialog operation is not simple. Having an extra operation for last may well increase simplicity. The trick is to look not from the language creator's point of view, but from the language user's point of view. If 90% of file dialog calls vary in only 3 of the 17 arguments, there should be at least a utility call for that case, with just those 3 arguments. In DSM, you may even decide to drop the other 14 arguments altogether: if anyone wants to use them, they can drop down to hand-code that part. That might even make the application's use of file dialogs more consistent -- how many times did someone choose a different value for a parameter just because they couldn't remember what the "company standard" way of using them was?

Part of the beauty of DSM is that the language can evolve, and the models update automatically (at least with a decent tool). If you find you actually need 4 arguments, you just add that 4th argument to the File Dialog object type, and all instances will automatically be updated with that 4th argument containing its default value. No need to update all your existing file dialog calls by hand, or to maintain both the new and old file dialog calls in the framework. One change by the language creator, in a few seconds, rather than a similar change by every developer, in every file dialog call, in every one of his models. Now that's both Humane and Minimal!