Re: [xml-dev] Feasibility of "do all application coding in theXML langua

["Steven J. DeRose" <sderose@acm.org>]

At 7:25 PM +0100 12/1/08, James Fuller wrote:
>  > 2. Game programming :)
>
>I am not a gamer, but I have heard that world of warcraft is heavily
>doped up with XML

Perhaps not "heavily", but World of Warcraft does specify the GUI 
using XML, and players use it in combination with a scripting 
language called Lua, to write add-ons.


As to the original question, it seems to me useful to make a few 
finer distinctions (not to mention defining what counts as an "XML 
language" -- Perl has some libraries for XML -- does that make it an 
"XML language"? ). But I think a more important distinction is:

     *Can* you do all application programming in XML languages
versus
     *Should* you....

XSLT is probably the clearest example of an "XML" programming 
language. There are claimed proofs that XSLT is Turing-complete. If 
those proofs are correct, then you can write anything in XSLT that 
you can write in any other computer language: any "computable" 
function (where "computable" has a particular formal definition -- it 
remains an open question whether you can thereby compute anything the 
human brain can de facto compute, but that's the present question).

Whether it is *wise* to do so depends on many factors:

If your application primarily involves documents, it likely is, 
because there is considerable cost to moving from one language to 
another in the middle of a processing stream.

But if (for example) you're doing a graphics-intensive application 
such as gaming, rendering a fully-animated movie, or simulating 
astronomical phenomena, XSLT would IMHO be a poor choice, because:

     a) there are few/no tools and libraries that are well optimized 
for such purposes

     b) if there were such tools and libraries, they were almost 
certainly not written in XSLT themselves, so wouldn't that be using 
non-XML-based tools anyway?

The point is not whether a new XSLT tool could be written that *was* 
optimized for graphical rendering, artificial intelligence, kernel 
implementation, microprogramming, CNC machining, or some other 
relatively-non-XML-ish domain; of course it could. But such tools 
often don't exist, which means that you'd have to invest an awful lot 
to implement and maintain one (especially one as good as the non-XML 
programming tools that *do* exist and already have maintainers, 
testers, programmers, advocates, and teachers already out there).

In other words, at some point the cost of moving data from one format 
to another can be greatly exceeded by the cost of implementing all 
the stuff you'd need. I know of no inherent/deontic moral virtue to 
XML; its value is utilitarian. So if the value equation doesn't work 
out, then I would say you shouldn't use it.

However, I suspect that a more common real-world difficulty people on 
this list face is that customers sometimes reject XML- solutions 
based on a very short-term calculation involving inertia rather than 
real costs and benefits, ignoring major costs/problems that follow.


Steve

-- 

Steve DeRose -- http://www.derose.net, email sderose@acm.org