XSLT and Ant: yacc!

This week I had to analyze the OSGi test suites for coverage. The test suites are an ongoing process so I decided to create a number of reports that cross link the OSGi specifications with the OSGi test cases. For release 3, I had developed an XML Doclet that generated a big XML file containing all details of the sources. The obvious route to generate my test coverage matrix therefore was to use XSLT, I already had the infrastructure.

Now, I do have a love-hate relationship with XSL. I have used it extensively in many projects: Ericsson e-box, OOPSLA 2001 and 2002, Deutsche Telekom eHome, and in , OSGi's member information system.

I like the power of the XPath expression language. It allows you to query an XML document in a very concise way (once you understand the concepts, which takes some time). However, I always dread the XSL part. The idea to use XML as a programming language is, well, eh, silly. Unfortunately, ant, maven, and many other applications have followed suit and used XML as their programming language.

So what are my objections against XML based programming languages?

Key is the extreme verbosity. Programming is one of the most challenging task that mankind ever came up with. A programming language is supposed to help you by simplifying that difficult task. Until XML came along, I actually believed we made some progress. The hex code I used in 1980 was terribly unreadable, assembly code improved it, then C was definitely more readable and it culminated (IMHO) in Smalltalk. Most modern procedural languages are fairly readable, at least their designers spend a considerable amount of time on it. Then suddenly XML hit the world and now an if-statement suddenly requires a tremendous amount of text, burying the meaning in an overload of brackets and quotes.

  void zoo(int b) {   <xsl:template name="zoo">
                       <xsl:param name="b" select="0"/>
     int a = 4;         <variable name="a" select="4"/>
     if ( b > 0 )       <xsl:choose>
                         <xsl:when test="b > 0">
       foo(a);            <xsl:call-template name="foo">
                           <xsl:with-param name="bar" select="$a"/>
                          </xsl:call-template>
                         </xsl:when>
     else                <xsl:otherwise>
       foo(b);            <xsl:call-template name="foo">
                           <xsl:with-param name="bar" select="$b"/>
                          </xsl:call-template>
                         </xsl:otherwise>
                        </xsl:choose>
 }                     </xsl:template>

Despite the silly syntax, writing XSLT is not that bad. With a good copy/paste training, you can write quite a lot of code in a short time. Actually, the verbosity makes your productivity measured in lines of code very good! The problem starts at debugging, especially if this happens a week after you did the writing. Information that is closely tied together is visually too far apart in XML based languages. For example, an assignment operation in XSLT separates the name from the value by cluttering the operation with the keywords: variable, name, select. All these keywords are implied by an assignment: a = 3.

Smaller is better, that is why we have subroutines. XSL has templates that can be treated as subroutines. Wonderful, except that the clutter of a template definition, and worse its invocation is so bad that it often makes the code more unreadable instead of cleaning it up. Add to this the dichotomy between the XPath language and XSLT (you can't call a template from XPath and you cannot define new XPath functions) and you have a complex mess that is no fun to work with.

XML is a very good way to communicate complex data. It standardizes the surprisingly complex problem of character encoding and escaping that made information exchange so error prone. However, it is intended to exchange information between computers and should not be abused to interact with humans, as it too often is.

So why do programmers more and more define their programming languages and configuration files in XML if the usability is so bad?

I think it is because it is the route of the least resistance. In the beginning of a project, XML is the easiest solution to get complex information from the end user (which is the developer). Parsing an XML file is trivial. Once the program is maturing, it becomes harder and harder to change the syntax. And it is not helped by the fact that today's programmers just do not know how to write a parser anymore. How many have used Yacc or its successors cup, javacc, etc.?

Our industry seems to have recognized that the usability of our products is crucial. It is odd that we do not apply those lessons to our own tools.

    Peter Kriens

posted by Peter @ Sunday, July 03, 2005