Category Archives: Code & Development

There seems to be quite a lot of activity on the “Domain Specific Language” front at the moment. Martin Fowler published “Language Workbenches: The Killer-App for Domain Specific Languages?”, in which he concludes that the common programming pattern of setting up repeating data structures via either very similar lines of code, or an external configuration file, is actually a DSL. He also republished a paper by Dave Thomas entitled “Design to Accomodate Change” on the related topic of table-driven programming.

However, Martin’s essay goes beyond common programming and data techniques to look at the development of specialist tools which he calls “Language Workbenches”. I’m not completely convinced that we need these in the world of XML and XSD. If you have a defined schema for you XML-based DSL (and aren’t all the many *ML langauges just different DLSs?) then any schema-sensitive editor will provide you with good design and editing support. The leading IDEs (e.g. Visual Studio) all have such a tool built into their core capabilities. Surely we now have a sufficiently sophisticated set of XML-based tools and standards that we have an opportunity to exploit synergies rather than re-inventing the wheel?

I’ve just read a wonderful paper by Guy L Steele, “Growing a Language“. He argues strongly that programming languages must be “small”, but able to grow. Such a language will have a relatively simple structure, syntactic rules, and a small core vocabulary. However it must also be able to “grow”, integrating new data types and functions, in the form of user code accessed in exactly the same way as core functions.

Steele’s argument is highlighted by the paper’s unique style – he uses a small but growing language himself. He writes using only words of one syllable, gradually adding other words he has defined in these terms.

The paper works at many levels. As well as the fascinating intellectual exercise in style, it makes a strong case for:

• simple but extensible programming languages,
• improving the extensibility of Java, rather than its core vocabulary,
• an agile community process for developing languages, rather than up-front design of great monoliths,
• the communication power of simple language and words.

Steele exhorts us to think about extensibility mechanisms – if we get these right then the core functionality can always grow. And by example, he encourages us to use simple, direct language and benefit from its discipline. On both accounts I agree wholeheartedly.

Integration, like other design activities, can benefit from sharing ideas and proven strategies in the form of patterns. An excellent starting point is Gregor Hohpe and Bobby Woolf’s Enterprise Integration Patterns website and book.

In my recent work I’ve discovered a few patterns of my own, and I’ve started a page to document them.

First up is entitled “Change Indicator” . You may have a legacy system with an EAI adaptor, or a similar source of messages, which reports on the current state of key business objects. The messages will typically tell you when something has changed, but not necessarily what has changed, but the latter may be important to downstream systems. This pattern shows how to use EAI elements to add this information in a way which is totally transparent to the legacy system and existing users of the EAI scheme.

In “Waltzing with Bears” Tom DeMarco and Tim Lister introduce the very useful concept of the “Uncertainty Diagram”, the probability distribution for project metrics such as delivery date, expenditure or benefit delivery. This is used, for example, to assess the likelihood of delay from a given risk.

However, they rely entirely on Monte-Carlo simulation. I believe that where the curve is defined by, or can be approximated by, a few discrete points, a relatively simple analytical solution can then be used in place of simulation.