I enjoy my occasional jousts with Steven Kelly from one of our competitors, so I had to respond to his latest missive.

 

Steven has posted a screencap of a long thread on our forum (how did you make that image BTW Steven?) and goes on to talk about a worry he has, that with many DSM tools (not including his own of course) there is still a lot of code needed to do simple customization tasks.  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".

 

Of course, it might have been a more convincing argument if Steven had had time to digest the code (or given it's not his product space, asked someone on the forum to explain it to him a bit more).  Then he'd have noticed that the original poster had actually posted a huge chunk out of his application, including a bunch of custom forms-based UI and a lot of the code necessary to integrate drag and drop between the Visual Studio "Server Explorer" and his DSL.

 

Generally speaking, I'm in full agreement with Steven that it should be as easy as possible to do simple customizations of a DSL.  This is something we call "avoiding the customization cliff", meaning that easy things should be easy to do and progressively more complex tasks should only get progressively harder to do, not insurmountably harder.

 

As George has started to point out, we're working hard to make our APIs drastically easier to work with than they have been in our CTPs so far.  However, as Steven is fond of pointing out, it will be a while until we hit version 4.5.

 

I do think the poster on the original thread showed the flipside rather elegantly though. There is a genuine need for the guts of the thing to be malleable.

 

Many folks won't have mature enough product sets to make the move to 100% app generation in a short space of time.  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.  The place that much of that traditional development will take place is inside regular IDEs. Some folks will want to tightly integrate the DSM development experience with the traditional.

 

If you're trying to add DSM capabilities to a technology that you sell which only addresses part of the solution space then tight IDE integration is a compelling customer feature because integrated features in an IDE drive productivity.  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.

 

We've always thought of Domains as a rich mixture world views, from end-users' company-specific vertical domains to SI's industry-specific domains and technology vendors' domains for the application of their technology to business problems.  We even think of the Forms designer in an IDE as a DSL, in the small domain of basic UI design.  Clearly there's a real diversity among these for just how much integration is desirable.

 

So Steven, I'm happy that it's one line of code to position a new shape in your tools, but 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?  Sooner or later somebody within the supply chain will want to do this stuff if we're really talking about DSM as a future broadly adopted technology.

 

Let's find ways to make the easy stuff easy but keep the powerful stuff possible.