I have heard that people think that Domain Specific Languages (DSL) is a very abstract concept. Because of the abstraction, a lot of people are nervous about domian specific languages. I can see how people get that impression. In order to have a DSL, someone uses abstract concepts to design the language. The goal of a DSL is actually quite the opposite. The goal of domain languages is to move away from the solution domain details and embrace the problem domain. What I mean is that instead of talking in abstract concepts like Classes and Components, we start using the domain concepts (Car, Truck, Node, Project, etc) when developing software. Describing aspects of a system in concrete terms makes it easier to understand the system.

By no means is this concept new. If you look at the history of software engineering you will see steady progress of moving away from the abstract concepts to a more logical concept. First, we started with machine code. I would argue that the machine language is a very abstract language to a human, while the most concrete language to a computer. We then move to assembly language. Assembly language made developing a little more concrete to us humans by representing op codes (numbers) as names, but assembly was not understandable to a computer. Therefore, the assembly language program had to be assembled to machine language so that the computer could understand. The assembled program became the artifact. Next came structured language and functional languages. At first people said that these languages could never produce code as well as programs written by hand in assembly. Over time, this statement was proven to be incorrect, and the object code became the artifact. Next came concepts like object oriented programming and aspect programming. Over and over the process repeats. We move to a logical reprsentation of the machine code. Each iteration makes that programming language more abstract to the computer but easier to understand for us humans. Domain specific languages simply repeat the cycle. Trying to make it easier to understand the concepts needed to develop software.

The previous statements are all fine and good, but is there any practical use? Yes, there are a number of examples of domain languages out in the world. If you look at NetBeans you will see a number of examples. The one that everyone will be most familar with is the form editor. It is a language that is designed specifically for designing user interfaces. As such, it is very intuitive to use and very powerful. The reason it is very intuitive is because it uses the concepts of a user interface to describe the user interface. It does not use general programming concepts of classes and components to describe a user interface. The form editor uses buttons, panels, labels, and a host of user interface controls to describe a user interface. To build the same user interface in code is very possible, but it is a lot of work. It takes a lot of work to get the control in the correct locations, not to mention how to handle resizing windows. However, when you use the form editor, this becomes a farily trivial task. Especially a form editor like Matisse. Note that in the form editor a lot of code still needs to be written. It is still up to the developer to write the user interface logic. The fact that the form editor leave a lot of code to be written by hand is a very improtant thing to note. A domain specific language does not mean that there will no longer be a need for a good source code editor. The goal of a domain specific language is to start generating more code not to do away with writing code.

Another example is the orchrastration editor. The orchrastration editor is a graphical editor that is designed to write BPEL documents. The orchrastration editor is an example of a domain specific language that represents not structural information but instead behavioral information. Even thougth the orchrastration editor represents behavioral information, it is still easy to use. It is easy to use because it uses the concepts of the BPEL domain to describe the behavior that is to be executed.

In my previous examples of domain specific languages, I have used graphical languages. Domain specifc languages are not limited to graphical languages. Indeed, there are may example of textual domain specfic languages. BPEL is a good example of a domain specific language that is a text based language instead of being a graphical language.

I can already hear the arguments that BPEL documents can easily be represented in a general purpose language like UML. That is a very true statement. The UML Activity diagram would be a very good fit to represent BPEL documents. As a matter of fact, I have made that argument myself many times. Also, a page flow diagram can easily be represented as by a state diagram. The point is that the higher the level of the language, the more intuitive the language. Now, I am not saying that there is no need for general pupose modeling languages. I believe that general pupose modeling languages like UML can be used to represent domain specific langauges, but that is a topic for latter discussion.

So, where does that leave us? Are domian specific languages by its nature abstract? Well, the designer of a domain specific language has to think about how to design the language. Usally the designing of a language will take you into abstraction. I would argue that the level of abstraction required to design a language is no more than it would take to build the concepts into a modern object oriented application. For example, to write an accounting applicaiton you would still have to develop the concepts of the accounting domain into your system. You would instead use the accounting terminology as an abstract concept, and the object oriented concepts as the concrete concepts. With domain specific languages, the domain concepts become the concrete concepts. Therefore, putting the focus on the problem domain insteading of focusing on the domian of the programming language.