Domain Specific Languages
2006-11-03
Last week I visited the OOPSLA in Portland to promote the OSGi. During that time I also visited many different sessions. Interestingly, only this week I started to see a trend in the conference, strangely enough not while I was there. Trends on OOPSLA are important; this is the conference where objects, patterns, aspects, and many other innovations were first discussed.
The trend is the focus on domain specific languages. We seem to be entering the time when Java is not the one size that fits all we something think it is. Interestingly, one of the key persons in the Java world (Guy Steele) had a presentation about Fortress, a language that is intended to replace Fortran. The syntax is highly optimized for mathematics. A key aspect is that the language should be readable by the domain experts. This means they have operator overloading because there are many mathematical operators that have formalized definitions. They allow the overloading of many Unicode characters, solving one of the problems with C++ where there were too few operators to work with.
However, there were many other presentations that address the language issue. A company called Intentional Software presented an editor that could display and edit the same abstract syntax tree in many different forms. This ranged from a mathematical expressions with all the nice looking formatting, to Java code, and all the way to the graphically display menu structure of a mobile phone. Again, the interesting aspect is that syntax does matter. But there was more. Another presentation told the story of a company that had 400 pages of requirements and domain knowledge. The estimate was that the system was roughly going to be 20.000 pages: a 50x increase in size. The presenter’s solution was to model the domain in a domain specific language and generate the system from the program written in that language. The expectation was that the system could be written in around 4000 pages of code. During the rest of the OOPSLA there were many more Domain Specific Language (DSL) presentations.
You see the shimmers of Domain Specific Languages in things like Ant and Maven. The XML files that parametrize Ant and Maven define a language. Unfortunately, they picked XML, which caused much of the clarity of a domain specific language to be lost in the sea of tags. Many developers have attempted to design domain specific languages using XML; the art of real language design seems lacking in today’s computer science classes. And it is so easy today with javacc, antlr, and other compiler compilers.
What does this mean for the OSGi service platform? The OSGi Service Platform is currently highly Java oriented, do we need other languages?
First there is already a domain specific language for Eclipse plugins called eScript, written as an example for the Eclipse FAQ book. Unfortunately it does not run as is on Eclipse 3.3, but it is an interesting approach. Instead of mucking around with MANIFEST.MF, plugin.xml, resources and Java code, it is all specified in one concise file. I think this approach is promising. An environment like Eclipse contains so much functionality, it would be very nice if one could tap into that functionality with a short script instead of all the work involved today.
I think the OSGi service platform is a great platform to provide the runtime for Domain Specific Languages. The OSGi provides a wonderful plumbing infrastructure for the generators that map the DSL programs. The nice thing about DSLs is that they only specify domain related issues and leave the plumbing and other chores to the environment. This implies that any overhead that the OSGi service platform requires can easily be created by the generators. This will make it very easy for people to write highly productive and specialized code while not being bothers with plumbing.
Look for DSL and you will find more than just modems. After a long time where very few languages were developed, I expect to see many domain languages to see the light in the coming years. I hope the Java community can embrace this opportunity by allowing these languages to run on the Java VMs and not oppose these innovations. Domain Specific Languages could be a great boon for our productivity, and could make the OSGi Service Platform more attractive to a larger audience.
Peter Kriens
The trend is the focus on domain specific languages. We seem to be entering the time when Java is not the one size that fits all we something think it is. Interestingly, one of the key persons in the Java world (Guy Steele) had a presentation about Fortress, a language that is intended to replace Fortran. The syntax is highly optimized for mathematics. A key aspect is that the language should be readable by the domain experts. This means they have operator overloading because there are many mathematical operators that have formalized definitions. They allow the overloading of many Unicode characters, solving one of the problems with C++ where there were too few operators to work with.
However, there were many other presentations that address the language issue. A company called Intentional Software presented an editor that could display and edit the same abstract syntax tree in many different forms. This ranged from a mathematical expressions with all the nice looking formatting, to Java code, and all the way to the graphically display menu structure of a mobile phone. Again, the interesting aspect is that syntax does matter. But there was more. Another presentation told the story of a company that had 400 pages of requirements and domain knowledge. The estimate was that the system was roughly going to be 20.000 pages: a 50x increase in size. The presenter’s solution was to model the domain in a domain specific language and generate the system from the program written in that language. The expectation was that the system could be written in around 4000 pages of code. During the rest of the OOPSLA there were many more Domain Specific Language (DSL) presentations.
You see the shimmers of Domain Specific Languages in things like Ant and Maven. The XML files that parametrize Ant and Maven define a language. Unfortunately, they picked XML, which caused much of the clarity of a domain specific language to be lost in the sea of tags. Many developers have attempted to design domain specific languages using XML; the art of real language design seems lacking in today’s computer science classes. And it is so easy today with javacc, antlr, and other compiler compilers.
What does this mean for the OSGi service platform? The OSGi Service Platform is currently highly Java oriented, do we need other languages?
First there is already a domain specific language for Eclipse plugins called eScript, written as an example for the Eclipse FAQ book. Unfortunately it does not run as is on Eclipse 3.3, but it is an interesting approach. Instead of mucking around with MANIFEST.MF, plugin.xml, resources and Java code, it is all specified in one concise file. I think this approach is promising. An environment like Eclipse contains so much functionality, it would be very nice if one could tap into that functionality with a short script instead of all the work involved today.
I think the OSGi service platform is a great platform to provide the runtime for Domain Specific Languages. The OSGi provides a wonderful plumbing infrastructure for the generators that map the DSL programs. The nice thing about DSLs is that they only specify domain related issues and leave the plumbing and other chores to the environment. This implies that any overhead that the OSGi service platform requires can easily be created by the generators. This will make it very easy for people to write highly productive and specialized code while not being bothers with plumbing.
Look for DSL and you will find more than just modems. After a long time where very few languages were developed, I expect to see many domain languages to see the light in the coming years. I hope the Java community can embrace this opportunity by allowing these languages to run on the Java VMs and not oppose these innovations. Domain Specific Languages could be a great boon for our productivity, and could make the OSGi Service Platform more attractive to a larger audience.
Peter Kriens
Add a comment
| Previous Posts | Archives |
|---|---|