<not-a-programming-language/>

I've recently had the chore (nee "opportunity") of putting together some test scripts using STAF/STAX. To be fair, I should also mention that IBM internally also has several layers of test tooling built on top of STAF and STAX to make testing "easier". "Easier" in the previous sentence was originally going to be "easier [sic]", but I'll withhold final judgement until I learn enough to have an informed opinion.

STAF makes a lot of sense to me -- it's a simple service-based distributed framework with enough low-level services (processes, events, logging, file manipulation, etc.) provided that you can build more interesting higher-level services.

STAX, however, just rubs me the wrong way. STAX is a programming language for test environments. For some reason known only to their mothers and respective deities, the folks who put together decided to use XML for a programming language. Now don't get me wrong -- I have nothing against XML per se. I have used it to represent data on several occasions and am continually amazed at the XSLT tricks that skilled practitioners manage to pull out of their butts. Let's consider briefly what makes XML a good way to express data.

1. It is self-contained. That is, you don't HAVE to have any external meta-information (character set, schema, etc.) to successfully parse it. This makes working with XML data fairly simple -- any XML parser can read any XML file. Note that this assumes you don't need to do validation -- that still requires some meta-information about what constitutes "valid".

2. The data is extensible. Namespaces allow 3rd (or 4th or 5th or...) parties to augment the data in any way they see fit without hosing each other.

3. There are really cool mechanisms like XPath, XQuery and XSLT that allow the data to be easily reorganized and combined with other data in ways the original author never intended.

How many of these are applicable to test scripts? Let's see...

1. What kind of metadata do you need for a test script? Perhaps some information about the environment needed to execute the script, change history, build instructions, etc. Does STAX let you put any of this in the test script? Not as far as I can tell. How about having multiple parsers? Only a test script interpreter/compiler is ever going to read these. We've known for decades how to define programming languages precisely enough that multiple people can independently write compilers.

2. You can't add new constructs to a programming language without hacking the interpreter/compiler.

3. I can't tell you how many times I've wanted to know how many "if" statements there are in my test scripts. Oh wait, yes I can -- NEVER!

And not only does using XML as a programming language NOT give you any benefits, you get to do a lot of extra typing as well! I need to scrounge some venture capital to start a company that manufactures steel <, > and / keys.


But the insanity doesn't stop there. The folks who put together STAX *were* bright enough to figure out that XML was totally inappropriate for writing expressions (which you tend to do a lot of in programming languages). Kudos for that. They elected to use Jython for expressions. Kudos again.

Now why the hell didn't they figure out that they should have used Jython (or Ruby or JavaScript or ...) for the whole language!?!