Friday, September 22, 2006

one mans programme is another mans data

Steve Loughran blogged (here) about this article from SD Times which slags off people for using XML to program things with, including Ant. I commented on Steve's blog but thought I'd reproduce, and extend that comment here, because I believe that the article is based on a false assumption.

That assumption is that people should need to read and understand XML programmes or data, and that size and efficiency are always core requirements.

"These sorts of XML “programs” are unreadable, unmaintainable, an order of magnitude larger than necessary, and audaciously inefficient at runtime."

I'm sure that comp sci students, academics and kernel hackers all care a lot about size and speed, and that anyone who has to read and maintain code will care about that too. But I'd counter his opinion by saying that XML is an easy to understand and powerful two dimensional technique for describing arbitrarly complex relational data, and that his "program" is my structured data.

Seems to me that the author has ignored the fact that ICT is moving towards a world in which people don't write programmes by hand anymore.
I don't mean low level stuff, I mean Big business and government Systems that have insanely short deadlines and dire consequences from defects and delays, people have enough trouble just Making These Things Work.
Tools are what deliver these things, and the tool's data is the system's programme.
XML allows you to describe and validate large and complex data structures in an open, standardised and accessable way, and if your valid data structure is also a programme it will be part of a system which is easily susceptable to being maintained by tools, and tools from many sources, not exclusively from your current supplier.
If you listen to people who think they can look a short way into the future they see that systems which alter their own programming are going to change the way that we think about ICT, and that that road leads us to a place where people won't know or understand the programmes, just the tools, we'll need to learn to write the tools, and to trust them. I think using XML to describe data, data which is also a programme, is a faltering first step on that evolutionary path, and we know its in use in this way all over the place already in rule specifications for all kinds of rules based processing, including things like Spring configuration, hibernate mappings etc. These things are programmes which should be maintained by tools, and programmes which could be modified by the systems which use them.
Ant's XML might not be a great example, for one thing there's no schema or DTD, but it is an example, look at all the IDE's which offer tool support for maintaining build.xml's.
I have no doubt that the use of XML in this way once again blurs the distinction between data and programme which is a key feature of really adaptive systems.


Anonymous said...

Wow. That made lots of sense.

Of course, it is quite possible to replace "XML" with some other technology, perhaps one which is a little more about being like a program and a little less about being like data (recently I learned about ASN.1, which I *like* so far). That's just muttering.

The overall direction you summarise here doesn't get worded well a lot, since it tends to get worded by business analysts (or microsoft saleS), but it's definitely there.

Unknown said...

Thanks Leo! I agree about the language, it could be any language, the point is that the languages which (IMO) will thrive are increasingly going to be the languages which are equally open to humans and machines. Those aren't necessarily the ones which are most attractive to comp-sci academics.

Newbie said...

Well, it is true that software development is moving more in the direction of utter simplicity and single-click "adacadabra" systems, and I agree about viewing software now as tools less than actual code /data.

Good article, good read..

blog comments powered by Disqus

I know nothing, I'm not a fortune teller, and you'd be insane to think that I am. This disclaimer was cribbed from an email footer I once received. It is so ridiculous I had to have it for myself.

Statements in this blog that are not purely historical are forward-looking statements including, without limitation, statements regarding my expectations, objectives, anticipations, plans, hopes, beliefs, intentions or strategies regarding the future. Factors that could cause actual results to differ materially from the forward looking statements include risks and uncertainties such as any unforeseen event or any unforeseen system failures, and other risks. It is important to note that actual outcomes could differ materially from those in such forward-looking statements.

Danny Angus Copyright © 2006-2013 (OMG that's seven years of this nonsense)