Ok, the researchers used Haskell to do the DSL, weird, they could have used Visual Studio Ultimate to do the same thing, at no cost to them with great efficiency. Well no matter, they did a good job and this article has a great title.
In this case, is Filet-O-Fish the best way to build a Domain Specific Language? I don’t think so, but what is cool about software is that I can put my words and thoughs into action if I disagree. Or I can blather rather grandly and in a lazy matter and just move on.
In the paper:
To quote the introduction:
The use of domain-specific languages (DSLs) to generate code for operating systems is a well-known technique, and it appears to offer significant benefits: programmers can express high-level ideas about the system at hand and avoid writing large quantities of formulaic C boilerplate. However, the idea has achieved little traction in the OS community so far: with the notable exception of interface definition languages for remote procedure call (RPC) stubs, most OS code is still written in a low-level language such as C. Where DSL code generators are used in an OS, they tend to be extremely simple in both syntax and semantics.
Well one of the reasons DSL is unpopular is because the programming language for the modeling is C. If I am a line programmer the first thing I want to do is tell my manager that you want to program anything in C. Most managers want you to write the specifications and have a program up and running.
The authors recommend higher level languages like Cyclone, Deputy or Sing#, seriously? Hey, there are tools that line programmers use, and if the researchers want to get others involved, it is a better idea to use tools that are more widely used. Sing# is an extension of Spec#, but even at that, Spec# is obscure and Sing# is even more obscure, oh well, guess I should blog about Sing# and Spec#. http://en.wikipedia.org/wiki/Sing_Sharp
An interesting approach, good outcome from the paper, made me think. Downside: Suggestions to use really obscure testing languages.