Domain specific languages – a technology coming of age?

Last week I was on a panel at the DATE (Design, Automation and Test in Europe) conference, debating programming MPSoC systems. The panel was well attended (about 100 persons bothered to show up) and there were some quite interesting discussions. At one point one of the attendees asked the question I was almost sure to show up: “When will we get rid of C and replace it with something better?”

As an answer, I cracked the joke about the Cobol programmer who gets so scared of the software he is supposed to fix prior to Y2K that he asks for being hibernated till 2020; however, when he is brought back to life, it turns out that there was a Y2K bug in the hibernating system and in fact he’s now in year 9998 – to the great relief of our distant descendents, as he seems to be the only person they could find capable of fixing the surviving Cobol programs as Y10K was knocking on the door. In short the answer was: never, we will never get rid of C – at least not for legacy software.

However the question itself brought back to attention the case building up in the background for high-level, yet efficient – in terms of productivity and performance – programming languages, at least within the limits of some well-specified domain. Stephen Mellor talked about executable UML and model transformation at the same event; my company is working on a high level language for DSP programming; Erlang is seeing an accelerating take-up and the list may continue.

Why is this happening now? There are two reasons.

The first relates to the constant pressure to reduce the cost of development while delivering increasingly more complex software. Ask any group of software development managers the question if they are ready to sacrifice say 20% for a 50% reduction in development cost and chances are that the overwhelming majority will choose the 50% reduction in development cost. Designing and verifying SW at a high abstraction level and then deploying efficient and automatic code transformation methods to get to efficient target software hold exactly this promise – and experimental results show that this promise may actually turn out to be true.

The second reason connects directly to the emergence of multi-core processors with ‘true’ parallelism. Sequential imperative languages are notoriously good at hiding or at least obfuscating inherent parallelism in the applications – which may be good news for compiler providers who spend – and charge – big bucks for building reverse engineering technologies that can detect parallelism from sequential code; as well as for highly skilled programmers capable of building parallel code using sequential tools; however, it weights heavily on the total cost of developing software, not to mention the recurring cost of porting to newer HW with e.g. more cores.

So how can domain specific languages help here?

Any language that has a claim at boosting productivity while having reasonable impact on performance must meet the following three requirements:

  • It shall have implicitly parallel semantics in order to support definition of parallel programs and facilitate deployment on multi-core chips
  • It shall provide domain specific constructs in order to facilitate productive code writing as well as help the compiler in generating efficient code
  • It shall deploy familiar language concepts programmers are used with

The first requirement provides the framework for supporting automatic mapping of applications to multi-core chips; the second supports productivity and expressiveness; the third one facilitates the acceptance by the community.

During the work on the domain-specific language for DSP programming we have seen some interesting results; for example, several pages of optimized C code were re-written to one PowerPoint slide worth of DSL code, while the DSL to C compiler was able to output efficient code comparable in size to the original code. We still have some work to do on making the language comply with the third requirement, but it really looks promising.

The big question is not anymore if DSLs will take off – it’s more if your pain level is higher than the cost of accepting an alternative and different approach; as the cost for taking in a new language tends to stay constant while the complexity of developing software is increasing, odds are that there will be an uptake of domain-specific languages.

The number of related questions I received from industrial participants after the panel at DATE seems to prove this point.

3 Responses to “Domain specific languages – a technology coming of age?”

  1. […] I hinted in a previous post, Ericsson was working, together with Chalmers University (in Gothenburg) and ELTE University (in […]

  2. Productivity says:

    Hi there I like your post