Juha-Pekka on DSM

Aligning a language closer to the problem to be tackled, regardless if the language is internal or external, represented as a graphical, textual, map, matrix etc. will almost automatically offer major improvements. Empirical studies (1, 2, 3, 4) have reported improvements for example in error detection and prevention, quality of code, productivity, maintainability and in communication and understanding of the system developed. The biggest improvements, however, are achieved when the level of abstraction is raised as high as possible. For me this means that the appropriate language-level abstraction should be the same as the problem domain. Or at least it should be as close as possible to the problem domain, area of interest that the language targets.

I have a pleasure joining the workshop on language design and implementation to defend my claim that the best level of abstraction for a language is as high as possible. I have no arguments against DSL'ish ideas of extending current programming languages, embedding a DSL to a host language, using better naming for API calls etc., but I don't see them raising the level of abstraction much from the implementation level. I'm afraid that these efforts then don't provide significant benefits to the development teams either.

At the workshop I plan to proof my claim by showing results from cases (partly public like 4, 5, 6, 7, 8, 9, 10) that develop and test different type of software, such as consumer electronics, telecommunication, product lines, medical, and automation systems with domain-specific languages, models and generators. These industry cases report 5-10 fold productivity increase. While many find such ratios hard to believe they are quite easy to demonstrate by showing some of the languages in action with a concrete case data. Obviously those cases target specific needs - as all DSLs - and the good way to find out if domain-specific modeling languages could help in a particular situation is trying it out, e.g. by running a short workshop as a proof-of-concept.

The industry cases also show that when raising the level of abstraction closer to the actual problem domain, traditional textual approach, dominating programming language design, is not necessarily the most suitable way. Instead the domain and the most "natural" way to express and find solutions in that domain should guide the language designers. For example, graphical block languages of Simulink and LabView have been de-facto way for engineers in signal processing and in control engineering, spreadsheets are heavily used in accounting, telecom standards are specified in MSCs of SDL, etc. Linear text presentation can still be generated to feed the compiler, integrate with existing libraries and code.

I can't avoid discussing tools, and I argue that the domain - area of interest - that the language addresses should again drive the language design, not the capabilities of a particular implementation technology or tool. Still DSLs can't survive without infrastructure such as tooling support. Too often companies have started to build this infrastructure along their DSLs, just to find out few years later that tool development is not their core business. And that building the tooling support took more time and effort than expected - yet to remember that tools need to be maintained too.

While metasystems, metaCASE tools, language workbenches etc. can help in creating the tooling support for the languages, such as editors, checkers and generators, most of them still require significant amount of resources (for a comparison of the creation functionality in tools, see [12]. Since maintaining the languages and supporting tooling is much bigger effort than their initial creation, perhaps at the workshop we can discuss issues after language design too. For example, at MetaCase we have tried to implement MetaEdit+ tool so that it supports also language maintenance, updates previously made models to a newer version of the language automatically (so that work is not lost and editors always open and work), support for multiple concurrent language engineers (each focus on different parts of the language (family), generators, testing while language is defined etc).

This year EC* 2013 combines ECMFA, ECOOP and ECSA and I expect that domain-specific languages and models are well covered from modeling, programming and architecture point of view!