Domain Specific Languages

From Jtkwiki
Jump to navigationJump to search

Domain Specific Languages (DSLs) are a relatively new trend related to Model Driven Development, Model Driven Architectures etc.

Design Remarks

Define Domain and Depth

It is important to define the domain of a DSL (obviously), and also to which depth the domain should be modelled. At the shallowest depth, a DSL is just a controlled vocabulary to describe a domain specific state, and some syntactic structure on the vocabulary elements. This corresponds to class diagram like models, such as those provided by the Eclipse Modelling Framework (EMF). DSLs at greater depth capture domain specific behaviour. Changes in depth and in behaviour frequently entail large scale changes in the design of a DSL (and the APIs supporting its implementation). From this perspective, decisions on DSL depth can be considered architectural decisions, as they are difficult to change once the DSL is realised.

Use Object Orientation With Class Names and Object Names

Where possible, DSLs should use basic object oriented patterns. Specifically, clearly indicating the class of each object in the DSL's object notation is very useful for human reading, parsing and transforming the DSL. Object names (or identifiers) incur some overhead and potential nuisance as they have to be kept unique. However, they are very useful to formulate operations on the DSL, which otherwise have to depend on unsafe and / or ad-hoc approaches, such as indexing. Notice that object names are not to be confused with variable names, as multiple variables can refer to the same object. From this perspective, JSON is a bad DSL (or template for DSLs), as it provides neither class names nor object names.

Misc Remarks

  • DSLs are frequently supported by an API and enable non-programmer user types to work with that API.
  • DSLs frequently mediate design of user interfaces

Spreadsheets as DSLs (??!)

Sometimes people come up with the idea that spreadsheets could be considered to be some kind of DSL. This doesn't seem to make much sense to me. The problem with spreadsheets is that there is no discernible language -- or at least, the spreadsheet language is very difficult to discern. It's not really possible to see the code of a spreadsheet, it's hidden in multiple places and you only can look at one or perhaps a few snippets at a time.

As a consequence of this, there's no chance to properly test a spreadsheet. In fact, I find that quite disturbing: People with perhaps rather limited programming experience and discipline type in code snippets that produce computed values and / or graphs, and these are then taken for the truth without any test or other evaluation. It's pretty inevitable that some of the results generated that way must be rubbish, and perhaps that's how some financial disasters arise...?