What should a domain specific language workbench look like?
I just got done looking at the Hello, world! tutorial of JetBrains MPS. It shows in disgusting detail how incredibly ridiculous this tool is. Not since JINI’s Hello, world! tutorial have I seen something that is such an anti-advertisement for a product.
So you might read this and ask, “if you’re so smart why don’t you come up with some huge language workbench and show them who’s boss?”. Well, I don’t have time for that, as I will not use enough domain specific languages over the breadth of my career to make it worth my while to write it myself nor am I interested in trying to sell such a thing. Instead I will give you a description of a product that I think people could use to do this that wouldn’t make them want to pull their hairs out one by one.
Let me lay out in broad swaths how my system would work:
1. First determine what your language info set is. In their example it would be a single string variable.
2. Now either write an XML schema or if you’re not a genius use Trang to generate one from some sample XML.
In their Hello World case we can use the sample XML:
Trang cleverly generates the following schema from this:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<xs:element name="HelloText" type="xs:string"/>
Which, being a genius, is exactly what I would have done. Now we have the info set for our little language. But who wants to type in that ugly XML stuff?
3. Transform the XML schema into a little language from requiring XML input to one based on a chosen style and structure.
For our case, we could choose C-style with a camelCase to whitespace transform.
4. From this generate a lexer, parser, and visitor specifically for this new language.
This mythical tool would then generate a lexer and parser that would take programs that look like this:
Hello text = "Hello, world!"
or maybe we would choose Lisp as our inspiration:
(HelloText "Hello, world!")
Of course the visitor supplied with the parser would then generate StaX events or DOM objects or some other XML representation that you could then use to execute this “code”.
Undoubtedly all of these transformations would of course be represented in some domain specific language perfectly suited to the task rather than having to click about 200 times on some terrible GUI interface.
5. For the coup de grace, provide a simple templating system like Velocity or GroovyTemplates to transform the XML into code that can be compiled or we could just choose to interpret the XML at runtime, like Spring does.
Now somebody out there go and write this thing so I don’t have to.