Following my comments about the long piece of layout code posted in the MS DSL Forums, there was a surprising amount of interest from the Microsoft gang (I made that a link just to drive some traffic their way: share and enjoy :->). Pedro Silva posted some code, and GarethJ posted some prose. I enjoyed both, and hopefully the discussion is helping people think around the issues of what kind of tools best support DSM. Here are some responses to Gareth's questions, most important stuff first:

How did you make that image? [920x9500 screenshot reduced to 12%]

Sounds like my screen is bigger than Gareth's ;-). Before he succumbs to screen envy I'd better come clean: about a dozen Alt PrintScrns interspersed with pastes and drags in Paint.

Now if I didn't know that it would rile him, I'd almost have been tempted to start this post with the word 'sigh'.

You should have done, Gareth - that would have been hilarious! Maybe a smiley after it to be on the safe side, although I have sometimes been known to recognize humor even without artificial aids. (If others don't get the joke, search for "sigh" in the case histories: Grady vs. Steve, Jack vs. Steve.)

If Steven had had time to digest the code... he'd have noticed that the original poster had actually posted a huge chunk out of his application.

I noticed (and ooh, how underestimated I feel ;->). My criticism about the length was mostly to question the wisdom of the OP in posting so much code. I thought I laid the humor on strongly enough in that first paragraph, but I'll remember to add some smileys too next time. Sorry if I unintentionally made the MS chaps feel a little bit annoyed. If I unintentionally annoy people, it's just clumsiness on my part. Intentionally annoy people, now that's a different story :-). Seriously though: I don't intentionally set out to annoy people, but I will say things I believe are important enough, even if I know it's likely to annoy some people.

For a long, long time, domain-specific development will sit side by side with more traditional methods and the two will need to integrate and play well together... It would be a shame if DSM technologies locked out these types of use-cases because they believe too strongly that they'll always have 100% of the application development pie to themselves.

Locked out? How?! The DSM tool generates code, so of course you still want a compiler for it. And of course you can open it in an IDE if you want. If you really like your IDE, you can generate a project file, so the generated code is all nice and easy to open. Whilst I'll be the first in line to tell you that you don't want your developers wasting their time looking at the generated code in general -- after all, how many look at the assembler from their C++, or byte code from Java, C# or Smalltalk -- you can of course build integration like that. It's easy, too: one of our customers in South Africa just went ahead and did it themselves, including being able to open models from the IDE. The MetaEdit+ API code for the latter part was five lines, and just worked (oh, and the IDE was Visual Studio -- another free plug for our esteemed competitor).

But let's say you want even tighter integration, as Gareth indicates:

Is it really only a few lines to integrate one of your DSM tools tightly with drag and drop to the Server Explorer in Visual Studio or to a forms designer in Eclipse?

No, probably not. But to be fair, what happens when you try to integrate Microsoft DSL Tools to something other than the exact same version of Microsoft Visual Studio? Drag and drop from DSL Tools to a forms designer in Eclipse, anyone? Or even trying to get last November's DSL Tools to work with January's Visual Studio -- fair enough, it's pre-beta so we can't expect compatibility yet, but will the long piece of code from the forum just work in the final release of the DSL Tools? Or in the next version of Visual Studio? Or even if you just change the modeling language a little? At what point will the tools be mature enough for that?

Of course, solving those problems is really just a technical challenge: it can be done, even if it does eat up development cycles for both Microsoft and their customers. The real question is how much you want such tighter integration. As ever, the best place to look is the change from assembler to 3GLs. Yes you can put a bit of assembler inline in some 3GLs (bit yucky, that), or certainly add it as an extra file in your build (although many "modern" languages won't let you do that anymore, or at least frown on it). But does anyone know an IDE where you could drag and drop bits of a 3GL into an assembler, and have things automagically happen based on that? Maybe such things existed for a short moment during the switch to 3GLs -- I know people then made the same arguments as Gareth now -- but they certainly don't appear to have been something developers actually found particularly useful.

Microsoft's focus on IDE integration seems to be leading many of its customers astray. They're jumping straight in to building tight integration with Visual Studio, before they've even had their modeling language used in practice. The 5-10x increase in productivity with DSM does NOT come from IDE integration -- none of the reported cases have had that. It comes from a good modeling language, fitting the needs of describing applications in that domain. Adding lots of funky integration between model elements and IDE behavior is breaking the "low coupling, high cohesion" rule, and creating a maintenance nightmare that will prevent the modeling language evolving. In many cases, that tight integration is going to be pulling the modeling languages right back down to the level of the code they are integrating with -- repeating the mistake of UML, which Microsoft had originally recognized so well.