First steps in creating an internal DSL with Groovy

Sten Anderson has a great post about creating an internal DSL with Groovy: A Text Adventure DSL in Groovy.

The "domain" of this example DSL is old-school adventure games like King's Quest.

The post shows the different steps how to transform the following Java-like code...

game.look();
game.go("north");
game.take("dagger");
game.take("sword");
game.take("key");
game.take("axe");

... into the following statements:

look
go north
take dagger
grab sword
hold key
yoink axe

Both of the above snippets are valid Groovy code that can be executed on the JVM!

To understand and learn about the implementation of internal DSLs I implemented this DSL example.

The project can be browsed and downloaded on my github account. The project is fully mavenized, and should easily be buildable and runnable with Maven.

follow me on twitter, I need some friends :-)

DSLs - 'faith no more' reloaded

Some month ago I was skeptical about lightheartedly jumping into DSL-creation, and I was wondering if I had lost my faith.

Then I realized that I was not the only one: Other people have lost their faith...

Now I realize this was all a spiritual tempest in a teacup. The wisdom was always there, you only had to listen to the right preachers:

Michael Feathers: How To Fail With External DSLs

There are more external DSLs out there than most people realize and more often than not, I see companies trying to get rid of them.

This is an interesting post by Michael Feather.
I did not know that Erlang was dropped by Ericsson (aka. open-sourced) because thy were concerned with their ability to hire and train developers.

The thing to remember about DSLs is that they are a commitment and the commitment doesn’t end when the initial implementation is done.

follow me on twitter, I need some friends :-)

Visual modeling: Is it worth it? An example...

The following link points to an interesting article (in German):

Groovy-DSLs mit Eclipse-GMF visualisieren

The article perfectly shows some of the issues I have with the current state of visual modeling and MDSD.

The first part of the article is about implementing a domain concept. This is directly connected to the business problem which should be solved by the software at hand.

The second part of the article is about making the solution of the first part accessible for visual modeling.

I did quite easily understand the first part. The second part however seems a lot like rocket science to me (or some secret ancient ritual). There are a lot of steps and different concepts involved (code, configuration, libraries, guis, wizards, repetitive reflection of the actual domain concept, mapping ...).

While I feel confident, that I learned something from the first part (creating a simple textual DSL with Groovy Builder), I do not have the feeling that I learned something useful from the second part, except that it is very complicated to use GMF...

In my opinion, as long as setting up (and maintaining) visual modeling for a certain concept is so much more complicated than the underlying concept itself, visual modeling hardly pays off!

You really have to evaluate costs versus benefits. And in my experience this is almost never done properly.
In the given article: What is the real benefit of visually modeling the process-chain?
Who is the target? Who will be using the visual modeling capabilities?
Are stake holders really able and willing to grasp the visual models? Or are you still going to communicate with them by Visio and Word?
If it is not for the stakeholders, do developers really like to work with the visual models, or is the simple textual DSL much more preferred by them (easier handling with current tools (refactoring, diffing, versioning ...))?

If you think about these questions, is the effort put into the infrastructure really worth it? The article says itself:

Indeed the learning curve [of GMF] is very steep. [...] To gain a better understanding there is often no other way than explore the GMF-Code with the help of a debugger.

This quote alone would rise a big questionmark if I were the project leader of a project that is actually supposed to provide business value...

In my opinion visual modeling is vastly overrated, and especially in the current state is hardly worth the effort.

In my experience any large-scale modeling efforts often turn very fast into a completely disconnected reality-loop. People are wasting a lot of effort just to conquer the accidental complexity that is introduced by the modeling requirement. The actual business requirement then comes only at second priority.

The metaphor that comes to my mind is this:
At the beginning you have a business goal, that is like the requirement to cross a river. But once you jumped into the river, you notice, that you vastly underestimated the current.
From now on you are fully occupied to keep your head over the water. Reaching the other side (not to mention at the specified spot) is of no priority at all any more.

follow me on twitter, I need some friends :-)

Maturity of DSLs as a concept

I like the following quote from Jay Field's screencast The 5 Ws of DSLs:

The DSL movement is in a stage that is similar to the stage of OO before Design Patterns were documented.

- Jay Fields, InfoQ

The concepts for DSLs are slowly being fleshed out. As experience is gained, best practices will evolve. But we are at the beginning of this process!


Along those lines:

Overuse of DSLs is one of the antipatterns in Groovy development.

- Dierk König, Gr8Conf

Do not create a DSL if a native solution would be as elegant.

- YADSL Rule

Some DSLs will live and some DSLs will die...

- Rocky Lothka, .NET Rocks Episode 417

follow me on twitter, I need some friends :-)

Raising the Level of Abstraction

Abstraction is a central concept in software development.
Abstraction is probably our only hope to conquer the ever rising complexity and requirements in current and future systems.

When designing a software system today often there are no physical constraints. The only constraints are intellectual: Is the design understandable, maintainable, what are the effects of future changes ...

Abstraction is supposed to be a tool to do the right choices when designing.
But what is abstraction really? How do you characterize it? How do you measure it?

There seem to be a lot of different notions about how to raise the abstraction level.

Some people talk about nonterminal symbols:

<integer> ::= ['-'] <digit> {<digit>}
<digit> ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'

Some people believe in pictures and visuals:

Some people see hope in reducing the signal-to-noise ratio of code:

[...] a lot of Java programs are the boiler plate of controlled structures with very little business logic. It's probably a four or five to one ratio between business logic and boiler plate control structures. So Ruby gives you that conciseness.
You are saying: "Here is the business logic, apply this business logic [...]

-- David Pollak, InfoQ

For me, the third approach is currently the most promising. That's where DDD tries to pull the lever. That's where concepts like the Ubiquitous Language and Domain Specific Languages try to provide value.


And finally remember Joel Spolsky's Law of Leaky Abstractions:

All non-trivial abstractions, to some degree, are leaky.

follow me on twitter, I need some friends :-)