WhatMakesAGoodDomainSpecificLanguage

From SPA Wiki

Thanks to everyone who attended the session! I've uploaded the (brief) session presentation 1 which includes a summary of the conclusions. Just to highlight them:

- It’s hard!

- Domain expert required

- Tends towards GPL

- Hard to scope language small enough

- Start with specific example statements

- Visual vs textual

- Bounded vs. unbounded

- Lots of little languages

- Unambiguous, expressive

- Fluent interfaces (vs terse or api)

- Learn from others (XML schema, OSS solutions . . .)

Feedback on the session:

On the whole it was very positive, but there were a few things that people struggled with. The biggest was that we didn't have real domain experts. Some of the teams just pretended and got very good results. Others had a harder time acting as if they were experts in the various e-commerce domains provided. The goal of picking e-commerce was to allow us to work on a domain that everyone would have some familiarity with so I'm not sure we could have picked an easier domain. Next time, however, I would provide more explicit instructions to the "customer" on each team to make them more comfortable with the process of being the expert - even if they weren't.

Some teams also struggled with having such a broad domain. The broad domain was deliberate. It's hard to know in advance what a given team will find interesting, so by picking a big domain (e-commerce) and then giving a specific suggestion (pet store, insurance, etc) as a starting point, the goal and the instructions were to help people by giving them a starting point and then to allow them to pick the specific language/domain that seemed of interest to the group - whether it be workflow, visual display, specific business rules or some other area that would be required by such a site.

One person commented that a little more teaching would have been useful for people without a background in DSLs. The goal of the session was to focus on the experience of actually trying to design a language so we could come up with some of the issues and I deliberately jumped straight into team work (which I think was good). Next time I would provide short 5 minute sessions after each session providing a little more theory to support what we just did and what we planned on doing.

The idea of naming the language to force people to be more specific and deliberate about their choices worked really well, although at least one team ended up with a generic name which really hurt them as they still had a collection of languages at the end of the session rather than one.

There was a lot of focus on creating example statements as the starting point. Unfortunately some of the teams understood the instruction but still had a hard time actually writing those statements. When they did, it forced the design choices and minimizing of scope which really helped.

I think in future I would actually do a worked example on the screen so that people would see an actual example. I think that by seeing what each step should look like it would have helped with people completing the exercises.

I think it would also run better as a longer session - I'd say it takes three hours including the theory and enough time to build something real and do a meaningful retrospective.

All that said, if the outcome of the session had been to create great, complete DSLs it would have been a failure. However, the real goal was to examine the difficulties of designing a DSL and the things to focus on, and by the end of the session I think the payoff slide of "things to consider" fitted very well with the experience of the teams and we got a number of additional points added to the final slide based on the retrospective. In short, I think it was a really useful exercise and a good way of introducing people to the actual experience of building a DSL. Looking forward to running this again somewhere else to continue to refine it.

Thanks again for everyone who came along, and feel free to add any other notes or thoughts below.

Peter