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?