Friday, January 19, 2007

A Note on DSL

"Our aim is your target!"


People like to do things in an easy way. What does easy mean? Looking for the definition in a dictionary, you find that it can mean “requiring little effort”, “free from trouble”, so that you know how to handle it at the first glance.
What do you do when you get a new machine? Say, a microwave? Well, I bet you won’t go through the tedious manual attached, but rather go ahead to the buttons and usually you have no problem to make it work. But how if the new machine is something you never touched before?
Similar things happen in engineering. With computer technology becoming ubiquitous and popular, most scientist and engineers in other domains, say mathematicians or physicians, tends to use computer programs help solving their problems. Those people have good backgroud in their major, but might not be a computer scientist, or even, a good programmar. As some of my friends, who are not doing CS, they always feel frustrated when it comes to programms. First, because of the restriction in the language, like grammars and syntax, it might be not easy to find a way to express what they want. In some case, it demands a lot of effort on converting the same knowledge into a totally different form, in which the process itself might be error-prone. While mathematics gives us a huge space for thinking and describing real world, it becomes pretty much in a restricted form when going to computer programs in a perticular programming languages. Second, because the program execution might not be consistant with the idea how problems get solved, it might lack precision and ability of being understood for the final results. These burden scientists or engineers with extra effort on dealing with programs and its analysis thus impaires their productivity and creativity in a non-trivial way.
There comes Domain Specific Languages (DSL) which is designed with a significant objective of making programming in the specific domain much easier. As a lot of people with great knowledge and bright ideas have worked on it for a long while, I doubt can I do better than than do? Well, here I'd like to quote some words from my advisor which is very encouraging (not taken literally): As far as we get this enthusiasm and have considerable background on both programming languages and the domain we are intrested, plus there is a need on this, we can definitely come up with some great idea.
This is of course not simple. First, we need to make it clear, what kind of language we desire. For those DSLs that are widely used and greatly admitted as a good DSL, , while some of them are doing a great job in their domain, some just win because of there "fluent interface". As said earlier, the target of a DSL is to ease the programming in a specific domain, a good interface that makes the program looks pretty much like the things it is describing of course weight. But is that enough? No, what's more important is how the language elements orgnized. Does the combining of language elements reflects the combining of ideas in the domain? So that it keeps all the power and flexibility of original world, e.g., mathematics? (Following graph described the desired language's position, which is in between pure mathematics and some existing languages.)




What's more, design process in the specific domain can gain advantage from a good DSL. For a design, we first have its specification, which portraits what we want. Then, there comes algorithms that aims at achieve this design. Finally, programs are just implementations of the algorithm in a specific language. For instance, when we want to sort a list of numbers, first we give the specification "the sorted list is a permutation of original list where numbers appear in a decendant (non-increment) order." We have tons of algorithm that might achieve this goal, to our knowledge, algorithms like quick sort, bubble sort, insertion sort are all correct ones. And we do have more incorrect ones. Finally, these algorithms are described in C, C++, Java, OCaml, Fortran, etc..
A good will is that we can program directly from specification, or more close to the specificaiton. This might be very expensive (for the example of sorting, list all the possible permutations and check the order one by one), and non practical at all. Whether the language is efficient seems not to be an interest here.