Coopetition
It's pretty nice to be able to work together to discuss and promote the parts of our respective visions that we share.
Still, just to show that the competition part is as healthy as the cooperation, Steven has a
post comparing a fragment of code I posted with how you'd do the same thing in MetaEdit. The code shows how to access link instances in a model using our respective templating languages. OK, so I'm biting ;-). What Steven doesn't mention is that he's comparing their product with an unfinished technical preview (to be fair, that's all he has to compare with right now).
Right now, the domain-specific API onto models that we generate is fairly strong in the area of classes, but weak in the area of relationships. You can access everything you need using our generic API, but today you don't get a nice, friendly, strongly-typed API for accessing your relationship instances.
Imagine for a moment that we did have such an API today.
The code we have for accessing class instances looks like this:
foreach ( ConceptB b in this.ConceptA.Bs)
{
}
It's not too big a stretch to imagine a nested loop:
foreach ( BReferencesB relationship in b.GetReferringBsLinks() )
{
}
Suddenly, the sample has much the same complexity as Steven's example.
In a later CTP, we'll have APIs more like this for link instance management.
The key here is to create the right domain-specific API, which is why we're not finalizing it in our early CTPs.
When you look at working with domain-specific APIs, then you have a good platform for making a decision on whether there is enough power in custom operators and the like to justify the extra learning needed to use a domain-specific language for the control-flow in templated artefact generation.
This Power vs Learning tradeoff will be one that will become familiar to all working with Domain Specific Languages when deciding whether they are a good fit as a solution for any given problem space.
