Wednesday, September 24, 2008

Article on Xtext and oAW

I just found a really nice article/tutorial on Xtext and oAW on the web.

It walks you through the process of
1) designing a dsl with xtext
2) adding constraints
3) enhancing the generated text editor
4) generating some code out of it
in great detail (about 30) and very well written.

The author comes to this nice conclusion :
Finally, consider the effort we had to invest. It took a couple of pages to describe the process, but when you count the actual lines of code we had to write and the number of clicks we had to perform, you may agree that this does not amount to anything worth worrying about. The framework kept most of the complexities away from us.
It is the power of frameworks like oAW that let us leverage the potential of DSLs and related concepts into our daily projects.
:-)

Thursday, September 18, 2008

Language feature supporting internal DSLs

There's a lot of discussion going on about internal or embedded DSLs and what programming languages are best suited to develop them.
Mainly an internal DSL is about pushing the syntactic flexibility of a language to it's limits in order to write against an API in a domain-specific manner. What that means depends on the DSL but in most cases it means simplification of client code by implying context, allowing declarativity and avoiding DRY-violation.

Many people think, that it is the dynamic nature of a language which makes it suitable for internal DSLs. That is only partly true. More important than the possibility to do meta programming is to have a flexible syntax allowing to invoke functions with different syntaxes (omitting paranthesis, semicolons, etc.). Ruby and Scala are both very flexible in this sense.

Working on the new version of Xtext, I had an idea for what I think would be a cool language feature.

Introducing new syntax via libraries
When declaring a function, one typically only declares a name and what kind of parameters need to be passed in. Programming languages themselfs then have defined a (more or less flexible) generic way of how such functions can be invoked.

Example:
def foo(String x) : "foo"+x;
which is invoked like this :
foo("bar")
Imagine a language which alternatively allows to specify the concrete syntax of how such a function is invoked.:
def  myFunc : 'foo' x=ID : "foo"+x;
Where the part between the first and the second colon introduces a new syntax (I've reused the Xtext syntax here) which can be used to invoke the function, so one could simply write:
foo bar
Where 'foo' is a newly introduced keyword (limited to the static scope where the definition is visible of course) and bar is an identifier which is a builtin lexer token of type String.

Another example:
def Person :
('girl'|male?='boy') name=ID (lastName=ID)? ('from' city=ID)? :
new Person(male,name,lastName,city);

def greet :
p1=Person 'greets' 'the'? p2=Person :
p2.greetedBy = p1;
which would allow for expressions like:
boy Sven from Kiel greets the girl Scarlett Johansson
and would effectively construct two instances of person and link them. :-)

Obviously this would be a tough thing to implement (parsers which dynamically change their behaviour) and it would also be problematic to avoid ambiguities with syntaxes imported by other libraries or introduced by the host language. I haven't spent much time on thinking it out yet. So maybe there are obvious show stoppers I overlooked or one of your neighbors has already developed such a language a decade ago?

Friday, September 05, 2008

Product-line engineering with UML

Some time ago one of our current customers, an international tractor manufacturer, wanted us to come up with a domain-specific language to describe his products (i.e. tractors) in order to manage the different variants, etc.

I always was really skeptical about using UML to define DSLs, but after investigating several month in tweaking it, we came up with an IMHO very pragmatic and concise solution.
With this a farmer is now able to simulate how it feels to work with the different tractors.
The DSL provides the typical variability people need, when defining a new product:
- number of wheels
- number of exhaust pipes
- whether the farmer wants to sit at the front or behind
- etc.

Here's an example of how such model looks like. Isn't that declarative and intentional?


With Ed on board and his new contacts at NASA, we hope we can reuse this DSL in order to model space ships, etc. at NASA.

Wednesday, September 03, 2008

Testing Processing Time on a JVM

I think most people would agree that having some unit tests, which ensures that non-functional requirements are met, is a good idea. With processing time people usually use time in order to measure whether a particular function runs within the requirements. However, everybody knows that measuring time is inaccurate, since it varies depending on the machine the tests are running and whether there are other process consuming resources in parallel.

Wouldn't it be cool to just count the atomic operations per thread executed by e.g. the Java VM?
We could than have a reference system, which is used to give each atomic operation a value (e.g. nanoseconds).

Then I would like to write tests like this:

@ExecutesIn(23000)
public void testFoo() {
doStuff("Foo "+" bar");
}

Where the number 23000 is the time it would take to run the code on the reference system. The test would always take the same time, no matter it was run on an x386 machine or a modern multi GHz box.

Questions:
Does anyone know whether such a tool/library/framework already exists?
And if not, do you have any idea of how this could be implemented?

Monday, September 01, 2008

DSLs in the Netherlands


Last friday I was in the Netherlands near Amsterdam to give a talk about Xtext at profict summer camp 2008. This was really a nice event in an impressing location (see picture - people work there!). They'd invited thee speakers:

First Neal Ford gave a very entertaining introduction on DSLs. After that he talked about implementing internal DSLs with Java, Groovy and Ruby. He also mentioned external DSLs very briefly and recommended Antlr for this very much.

His talk gave a nice foundation for my introduction of Xtext. Which I did by leveraging the terminalogy Neal introduced (As Neal is a collegue of Martin Fowler and has done a lot talks on DSLs with him, I assumed that he will stick to Martin's terminology and I was right) . I also showed the implementation of the example from Martin Fowler's upcoming Book on DSLs, which should help to compare the different technologies (internal DSL in Ruby, Antlr, Xtext).
I've been asked to put my presentation slides online. So here they are.

The last presenter, Zef Hemel from TU Delft, showed us a web framework called WebDSL, which uses a lot of external DSLs to make development of database driven web applications (CRUD and more) easier. It is implemented in strategoXT, which is crazy stuff.

After that there was a panel while outdoor a great smelling barbecue was prepared. Unfortunately I had to catch my flight back, so I had to leave without any barbecue :-(.
Anyway the event was really nice and I've met a lot of very nice people there. It seems that DSLs are a hot topic in the Netherlands.

Ed Merks now working for itemis

Last Friday, Ed Merks (Eclipse Modeling PMC Lead, EMF Lead, Board Member... you know him) has officially announced that he's now working for itemis AG.
I'm especially happy with this because when I first heard that Ed has quitted IBM, I was a bit worried whether he would be able to do the great job he's doing at Eclipse in the future.

I'm pretty sure that this was a good step, not only for itemis and Ed but also for Eclipse and Eclipse Modeling, since this ensures that Ed can follow up on helping Eclipse Modeling becoming the most open, flexible and powerful DSL toolkit.

Why? Because the business model of itemis is not to develop another commercial product on top of Eclipse but to help people using the open-source technology at Eclipse directly (we're doing consulting, trainings, support, etc. then).

And we don't want to do consulting which could be eliminated by better tools and better documentation. We think that DSLs and generators/interpreters will and should become mainstream. Therefore we need to lower the barriers and make the tools and languages as good as possible. We want to make software development better. AFAIK this doesn't conflict with Ed's goals :-)