Programming in XML — Spaghetti code squared

Do you still have any part of your application that doesn’t use XML? I can’t find many in mine. It’s all fine if you’re using XML in the right place and for the right purpose. Heaven help you if you start using it for things it wasn’t designed to do. Probably the most disastrous example of misusing XML is using it to write an algorithm, which is to say, programming in it. Do you know Ant? Everyone knows Ant. Why am I even asking?

Ant is a simple idea. It’s a build tool, and you describe what you want in XML. The trouble starts when you need even slightly more complicated constructs. Before long you find you need a condition here, a variable change there, and a loop somewhere else. The following code shows what that looks like.

Now imagine tens or hundreds of kilobytes of code like this. I said code, as in program code. Unfortunately XML wasn’t designed for writing programs, so validation is the only help your IDE can offer. It may be 2008, but forget debugging, syntax highlighting, or refactoring. So after a while, if you decide to program in XML, you’ll be left with one big ball of spaghetti that nobody will ever be able to do anything with.

I wrote much of our product’s installation process and extension mechanism in XML, specifically in Ant. Today I consider that a big mistake, a monumental one, in fact. The only advantage is that everyone knows Ant. So someone can come after me, and someone else after that, and make whatever changes they need. Essentially they just add another layer of spaghetti.

My lesson from all this is that XML isn’t a programming language. You can’t manage it effectively, so if you use it to describe your programs’ algorithms, sooner or later you’ll have tons of text that’s good for little more than throwing away.

All right, enough taking shots at my own work. What would I do today if I could start over? I need something that lets me concentrate on the problem at hand, such as copying, deleting, renaming and archiving files, replacing text in a file, or applying an XSLT transformation. I also need to be able to use the power of a programming language, including conditionals, loops and recursion, and the support an IDE provides for debugging, syntax highlighting and refactoring.

That leads me to create my own DSL, or something I might call a DSL in quotation marks, so I can express myself effectively in that context. I’ll illustrate it with the following code, a rewrite of the XML above.

someDir.eachFileRecurse() { f ->    
    if(f.nameContains("hibernate") {
      //do something with hibernate
    } else {
      //do something else
    }
}

This is a snippet in the programming language Groovy, which you can use, among other things, to create your own DSL. I could of course use Ruby, for example, which some people might find an even better choice for a DSL. To each their own. Groovy would give me exactly the programming-language features I need and mentioned above. A DSL tailored to the problem would let me express the algorithm much better.

Don’t make the mistake I made. Use technologies for what they were designed to do, and for nothing else.