DSLs in the field

The HPLabs Smartfrog system (http://smartfrog.org/) is a declarative template language for describing deployments, including all the configuration bits that cause the real problems.

You hand it off to the nodes you want to deploy to, and between them they create, configure and then deploy things in the order you declared.

No, its not XML. Like RelaxNG, its opted to be usable by people, which is a mixed blessing. It may be a cleaner syntax, but its still another syntax to learn.

Interesting post. Nevertheless I hope in a standardization and unification of the business process schema.

These examples are very computer oriented, "horizontal" technical framework-like stuff, and mostly target software vendors.

I don't think anyone can seriously use the existing DSL tools shipping with VS 2005 to produce real world domain languages.

I hate that. DSLam says that existing DSL tools shipping with VS2005 wont be used to produce real world domain languages, and for someone like me who hasn't had the chance to check them out, i would really like to see along with this statement the reason WHY !

John DSLam is simply mistaken. That is all. We are early in the evolution of DSL that is all. Don's examples are perfect to illustrate this in that they are almost all targeted at the developer. Once they and the tooling go through refinements, the tooling will move up another level. Once that happens is when it becomes real.

We are simply early in the process and it will evolve and mature. That is unless Grady and others have their way....

DSLam doesn't think anyone can use the DSL tools to produce real world domain languages. Well, they are still early technology previews - they don't ship until next year. But DSLam is, as you say, mistaken. We have customers today who are using them in real world situations and planning to put them into production. You will see.

Don: Your examples are great, but Grady was actually talking about *graphical* DSLs, i.e. Domain-Specific Modeling languages. The difference is important, because whilst a textual DSL increases productivity, a graphical version increases it even more (see David Weiss's book from his work at Lucent, for instance).

DSLam: I've followed the Microsoft DSL tools for a year now, and just been on a course on them. As a competitor to them I hope you'll find it believable when I say I'm sure they will be able to be used when released next year, and will improve over the coming years.

If you want something serious now, you might want to take a look at our MetaEdit+(http://www.metacase.com). It gives you results several times faster, and has been used successfully to build hundreds of DSM languages over the last ten years.

In general DSM is about generating full applications from models - either by generating code or by outputting some other format that is read by some kind of engine. In any case, both modeling langauge and generator are made by the customer specifically for their narrow domain, and the kind of code they write. This avoids the problem of one-size-fits-all solutions, and the verbose, inefficient, "vendor knows best" generators that went with them in 80s CASE tools and today's UML tools.

Of course, the UML vendors don't like this threat to their status, as can be seen in the false accusations made by Grady in the link at the top. He really did say "I typically throw my models away" - whether or not he has later wanted to explain that he only meant *some* models!

@DSLam: we are in the middle of writing a "real world" DSL for modelling services. all in a very early stage. the current DSL tools have some shortcomings but it is definately possible to write "real world" DSL's with them. I can of course only speak for myself but we plan to make our DSL availabe just after the official release of the DSL Tools.
so I think have to disagree with you on this....

Don Box says "In my mind, the only way this stuff will get traction is if we change the runtimes...

Don, as usual, is poerceiving the real problem here. Steve Cook, however, is also aware of the problem - the falling of the cliff if and when you step outside the model, and they have shown an understanding of the problem and pointed at solutions.
I remain optimistic, but there is a lot of work to do.

DSLam,

Your comment about "computer oriented" is interesting.

The DSL "opcodes" (a.k.a. activities) we ship in the box with WF are fairly general purpose for modeling control flow and process interactions.

The expectation is that users will write activities that are specific to their problem domain and use the WF execution engine, designer surface, and XAML representation to stich it all together.

If you look at the XAML that ChrisAn and I wrote in our latest MSDN TV episode (http://msdn.microsoft.com/msdntv/episode.aspx?xml=episodes/en/20051215WinFXCA/manifest.xml), we defined two activities that were specific to a given domain (in our case music) and then stictched them together using the WF designer and XAML.

Because we composed our activities with some control flow activities that WF provides out of the box, we were able to compose a song in pure XAML.

Cheers,
DB

Steven,

The approach we took with WF was that there's a textual represenation (XAML) with an optional visual design surface.

When you write a new activity, you can write your own visualization and editing experience, but if you don't, we'll provide one for you.

Boxes and arrows are great for humans, but remember that we're trying to make these models useful to the actual runtime environment, so a machine-readable form is an absolute must. The fact that we also ship a designer is fantastic, but a designer alone ain't enough.

DB

Grady Booch @ the OOPSLA 05 Structured Design and Modern Software Practices Panel at (according to the...

Grady Booch @ the OOPSLA 05 Structured Design and Modern Software Practices Panel at (according to the...

I would say Microsoft's IBF (Information Bridge Framework) is a DSL and a good candidate for modelling purposes...

A company called Bridgewerx (http://www.bridgewerx.com) has built a "visual" DSL (using FLEX) on top of BizTalk Server. The purpose of the DSL is to provide a higher level of abstractiion so that a Business Analyst using the DSL Visual Designer can model application integration solutions and the output of the DSL is an XML definition that populates a Visual Studio solution using a Software Factory approach to code generate the application integration solution.

This is a real commercial shipping product. The gory details of how it works, including a Microsoft Live Meeting webcast can be seen at:
http://softwareindustrialziation.com

Cheers,

Mitch

My comments were really about the DSL tools, not the DSL idea itself. IMHO, DSL Tools that ship with VStudio 2005 are far from what we expected when all this was announced.

Again, I don't see any Domain, except "computer-ish" ones that DSL tools can reasonably help implement. The fact that most samples are about Entity/Class/UML-like models is actually enlightning.

Plus, the learning curve and the investment is just too important. One has to master not only the VStudio environment (IDE) but also VSIP (VStudio SDK) and the DSL tools itself. And finally. The only benefit I see is 1) shape drawing, 2) shape connectors, 3) VS integration, and these are not brought by DSL tools, but by what was once called "Whitehorse", which is now embedding in Visual Studio. BTW, why whitehorse is not exposed publicly is actually another question...

Don, about WWF, I think it's a great idea, and a great tool as well. But I don't see how is this related to DSL Tools. I don't think WWF is using DSL tools. It may be using "Whitehorse"...

I think every yahoo in the world who likes to re-invent the wheel will be putting out their own designers. This now ticks me off as much as the MSF did when it claimed to be a process framework when it first came out. . .
Full Read...
http://realworldsa.blogspot.com/2005/12/vsts2005-dsl-and-software-architecture.html

GAT/GAX is a different story... The Guidance Automation Toolkit (GAT) has potential to be a very useful tool if the organization is willing to make the upfront investment in an Architectural Driven Development process or a Product Line Engineering (PLE) process.
Full Read ...
http://realworldsa.blogspot.com/2005/12/guidance-automation-toolkit-gat.html

Ah, very nice ....
The mother of all battles is about to start. The final war on ideology of making software...Lords of UML v.s. the young knights of DSL !
UML side has the experience, while the other side has ..... what ?