Last week Jimmy Nilsson expressed his growing dislike for today’s overuse of XML, particularly when conceived as a surrogate programming language.
I really share Jimmy’s concern, especially when I think about the XML abuse I’ve been subjected to while creating languages and recipes using the Domain-Specific Language (DSL) Tools and the Guidance Automation Toolkit (GAT).
On the other hand, I recognize that it is totally unfair for me to complain; this is, after all, the price we pay for dealing with prerelease software.
In fact, the DSL Tools team already announced that will soon provide us with a modeling language able to deal with the .dsldd file and hide that ugly XML from our sensitive eyes.
I haven’t heard of announcements regarding similar improvements on the GAT side, but I choose to be optimistic and wait for new developments.
Unfortunately this problem does not affect prereleases exclusively; released software, both closed and open source, is not immune either.
Let’s face it, it is far too easy to define and process a language using XML for not taking advantage of it; in a not-that-distant future, however, I have no doubts that we will look back and laugh thinking about how we put up with manually dealing with its angle brackets notation on a daily basis for all these years.
Apart from really extreme cases such as XSLT, perhaps XML-based build languages of the likes of Ant, NAnt and MSBuild are among the most obvious and discussed examples of how a good idea can turn nasty when scenarios get a little more complex than anticipated.
Martin Fowler already suggested that today’s enterprise applications require pretty sophisticated builds which are better handled using a full-fledged programming language.
Last year, he also wrote an article about his explorations using Rake, a build language based on Ruby. In a nutshell, using an internal (text-based) domain-specific language such as Rake enables developers to easily switch to the external general-purpose language (Ruby) whenever necessary.
But how sophisticated can builds be? To put a little bit of perspective into things, let me tell you that for more than two years at InnerWorkings we have adopted a continuous integration solution based on CruiseControl. NET and NAnt; unless you’ve read Jimmy’s brilliant manuscript of his upcoming book (in which I was honored to make a small contribution as guest author) you will be surprised to hear that we manage to automatically and continuously build, obfuscate, package, test and deploy several hundred .NET solutions.
While I think that we have done more than a reasonable job at maintaining a good degree of modularity and reuse in our XML scripts, our tolerance to NAnt’s notation has been tested several times.
Resorting to a DSL written on top of a full programming language as Martin suggests would definitely help, but I have the impression that a purely text-based language may still be rather inadequate at solving one of the issues that we often face, particularly when dealing with many scripts in parallel like our scenario requires: lack of run-time visibility about the progress of each build.
Do I have a viable solution? I’m not sure, but I speculate that it won’t be long before we will see the raise of a new generation of continuous integration systems built around the upcoming Windows Workflow Foundation, with steps defined using domain-specific activities.
What do you think? Is it a daft idea?
This Post Has One Comment
Well, I suppose you are right. The situation is the same as in case of UML. If something is for everything, in fact, it is for nothing when it comes to real, advanced scenarios. XML is easy to use at the beginning but, as you said, when you want to do something advanced it’s painful process. WF sounds reasonable.
Comments are closed.