<< Integrating NHibernate and Active Record | Home | Putting the container to work: Refactoring NServiceBus configuration >>

Notes on versioning Domain Specific Languages

Those are just a few topics that I feel are important for discussion when talking about versioning DSL:

  • Different behavior at runtime
  • API vs. Syntax
  • Different dialects
  • Backward and forward Compatibility
  • Pros:
    • Keeping existing assets
    • Training
    • Knowledge
    • The Test of Fire
  • Cons:
    • Increased costs
    • Harder to change
  • Preparing for versioning:
    • Syntax Documentation
    • Closed world - control what you can access
    • Limit to a scenario
  • Versioning strategies:
    • The Holy Compatibility
    • Build & abandon
    • Version marker
    • The Big Upgrade

Thoughts?

Print | posted on Sunday, July 13, 2008 12:29 PM

Feedback

Gravatar

# re: Notes on versioning Domain Specific Languages 7/14/2008 8:26 PM naraga

API vs. Syntax is actualy very interesting. i'm wondering whether it would be possible to build such object model (with some attributes decoration) that language syntax could be inferred. this could be another facade for the system. i'm not saying that this general purpose approach fits all scenarious. in fact i think that it really lacks core advantage of DSL which is to be fine-tuned for specific domain. but still it can be usefull at least for writing some kind of automated integration tests.

Gravatar

# re: Notes on versioning Domain Specific Languages 7/14/2008 8:37 PM Ayende Rahien

Naraga,
The way I design most DSL today is by careful use of language feature to allow the API to drive the syntax.
As a simple example:

for type in AllTypesBased of IController("MyApp.Web"):

Gravatar

# re: Notes on versioning Domain Specific Languages 7/14/2008 9:04 PM naraga

yes, i remember this stuff from your past articles - boo dsl. but do you think it is possible (or have you explored) to automatically generate syntax from something that Fowler calls "Semantic Model" ?

Gravatar

# re: Notes on versioning Domain Specific Languages 7/14/2008 9:21 PM Ayende Rahien

Not really. At least not unless your semantic model is targeted as the language itself, and not the real model.

The issue here is that you usually need a facade between the two, to allow better syntax to the language.
You can play a lot with conventions, for sure, but I am not sure it if wouldn't hurt the language

Gravatar

# re: Notes on versioning Domain Specific Languages 7/14/2008 10:36 PM naraga

for sure the comfort of such language will never be comparable to dsl that was designed with syntax "ergonomy" in mind. btw. this semantic model would be in fact dedicated facade. something thats solely purpose is to help to generate parser or even executable engine. maybe this aproach is already implemented to some degree or maybe it is pure nonsense :)

Gravatar

# re: Notes on versioning Domain Specific Languages 7/21/2008 7:18 PM Damon Wilder Carr


NOTE: A more detailed post is in the 'why Commons' post but it covers the issue of reuse more which is not relevant here.


When I start working with teams and say the correctness/utility will often not even be quantified if the usability is not there. But then we have the issue of 'personal style'.

As there are many ways to expose functionality (but thank god we now are almost there with a far more concrete standard which I think Rhino Mocks is a perfect example of) or the 'in process' 'Expression Builder' (as Fowler calls it in his new DSL book) style.

But even that is known by what, 5% of us? Less? Fewer still have the skill to write to it, as you (amazingly to me) power it out for the NHibernate Query Generator when I knew that was what I wanted, but I was sure not going to do what you did (grin). Thank god you did however.....

And you see how you loved the Rhino Mock work when asked about what you enjoyed. I would submit the best 'architects'/whatever will enjoy this work the most as it fundamentally makes others so much better.

Also it STARTS with the set of nice utility calls. But the end-state absolutely in my opinion needs to be a technical DSL (I disagree with your position here on C# 3.0 as I find is more then good when combined with Custom Linq Providers as in 'Linq to Your Domain').

So we over time evolve this into the 'technical' bits, and indeed into the more holistic DSLs (I always end up with a portfolio of DSLs across targets, and your right, I'm struggling with these decisions on how to seamless transition the experience from say the Microsoft DSL Graphical DSLs with code gen to the more details work done in the textual C# 3.0 internal DSLs. It works but will get better.

Anyway, not an answer but more questions (grin)..

Damon Wilder Carr
http://blog.domaindotnet.com

Comments have been closed on this topic.