Fog Creek Software
Discussion Board

XML the COBOL of the 21st Century

This was a title of an article I was going to write sometime last year.  As usual the best part of it was the title.

The current hype of making XML processors reminds me of IBM's positioning of COBOL as managers taking control of computers from the high priests in white coats.

It was a reasonable goal, to let middle managers describe the things they needed done in as near a plain english form as possible.  Its flaw though was that managers really didn't want to get into the fog of writing software when budget management and executive toilets were their focus.  It did however increase the accessibility of software development to ordinary (though large) companies.

Identifying XML (or more accurately SGML dialects) as being a panacea for everything from data storage to data presentation and processing is just the latest attempt to make the complex seem accessible to ordinary people.

But in reality the complex is still complex.  XML is not the best for everything just as my underpants make very poor socks, although if push came to shove I could convert my underpants to socks if I had the mind to.

Simon Lucy
Thursday, November 15, 2001

XML is the CSV of the late 90s.

Jamie Anstice
Thursday, November 15, 2001

Just to put your panaceas in one basket: there is a COBOL for .NET out there, so you can get your XML and your COBOL in one tasty (?) package.

Mike Gunderloy
Thursday, November 15, 2001

Java is the COBOL of the New Millennium.

Just about everyone I've seen redeveloping COBOL apps does it in Java; it's occupying the same niche in financial services organisations.

XML is indeed the CSV of the new generation - it's a lot saner than CSV, but unfortunately people keep trying to do stupid things with it.

Rodger Donaldson
Thursday, November 15, 2001

People will always find a way to do stupid things with new tools.  Nothing will every be idiot proof, the idiots are too darn inventive. 

Anyway, if you consider that that XML is not an attempt at a programming language so much as a data formatting language, I don't think it "could" be the COBOL of the 21st Century.

(Just a nobody)

Bill Dunsford
Thursday, November 15, 2001

Its interesting how stuck with categories we get.

And the reactions show the divide about what XML is quite neatly.  Yes XML can define data (content) but it can also define behaviour (XUL etc).

Java is much more like the Pascal of the 21st Century, its nasty and smelly to actually implement but is fine for those that use it.

The point I was making (and failing), was the intention behind XML.

Simon Lucy
Friday, November 16, 2001

XML can be used to describe user interface (XUL), but it does not define the behaviour.  You have to _interpret_ the description, but the interpretation is, say, application dependent.

XML is _not_ a programming language and it cannot be compared with COBOL, Java, Pascal, or anything else.
XML can be used to describe the structure, the content, and the meaning of possibly very complex data structures.

Niclaus Wirth, the author of Pascal, wrote well known book: "Algorithms + Data Structures = Program" -- this was before OOP, but it fits with Pascal.  In this context, XML would be the "Data Structures", and never "Algorithms" (i.e. no program can be written using XML).

To summarize: XML will never be the COBOL of the 21st Century.  As someone else said "XML is ASCII of the future".

You can find more details in my reply to "XML" topic started by Nigel Soden.

Petr Prikryl
Wednesday, November 21, 2001

This is what I was meaning by being locked into categories.  I wasn't actually comparing XML to COBOL as a programming language.  However, XML certainly is not the 'ASCII of the future' and as it happens yes you can define behaviours for XUL, though its in CSS.

You could certainly define a programming language in XML and that would be interpreted at 'runtime' by some parser or other, just as with any other interpreted language. 

Something like,

<codeblock name="Hello World">
    <loop count=100>
                "Hello World"

It could consist of conditionals, unconditional branches, events, switches and pretty much anything else.  Whether it would be useful or not is beside the point :-).

Because there's no constraint on what a property on a tag can have, other than it being an entity that can be parsed you can also embed scripting such as:

<somefunnytag  conditionalbit="if (splinge='yes') {current.splinge = true; } else { dosomethingelse(); current.spling = false ;} >

It all depends on the interpreter, but then it always has.

Simon Lucy
Thursday, November 22, 2001

Windows Scripting Host already does this. For example, this is a perfectly legal script:

<?XML version="1.0" standalone="yes" ?>
  <job id="DoneInVBS">
  <?job debug="true"?>
      <script language="VBScript">
        WScript.Echo "This is VBScript"

  <job id="DoneInJS">
  <?job debug="true"?>
      <script language="JScript">
        WScript.Echo("This is JScript");

Mike Gunderloy
Thursday, November 22, 2001

I still have to disagree with Simon Lucy and Mike Gunderloy that XML gives you some processing power, and that it can be compared with programming languages.

Simon Lucy wrote:
"However, XML certainly is not the 'ASCII of the future' and as it happens yes you can define behaviours for XUL, though its in CSS."

Well, but you are only _describing_ the behaviour. CSS or whatever similar is only another description.  You still have to have some interpreter -- say the web browser.  You could do the same with ASCII.  Think about shell scripts or batch files! Do they have any processing power?  This is the shell or or something similar that is needed to execute the script.

Can I say "DOS batch files are COBOL of the 22nd Century"?  I don't think so.  And still, you can run whatever from your batch file (the does that for you; batch file is only some ASCII file with special syntax).

Simon also wrote:
"You could certainly define a programming language in XML and that would be interpreted at 'runtime' by some parser or other, just as with any other interpreted language."

I would say that you can write only a source code in XML. You can capture some semantics in some tags, but it does not give you any computing power.

What about ASCII.  I believe that majority of programming languages uses ASCII for capturing source code, don't they? ;-)  What makes XML different in your example?

Some remarks to Mike Gunderloy's example:
In XML, you can define processing instructions (with question marks near the angle brackets), but you still need some interpreter to process them.  Also the script tag must be interpreted -- the Windows Scripting Host is your interpreter.  As Mike wrote in front of his example, it is only a _script_. The ASCII has the same "processing power" as the mentioned XML-document example.

Do you still think that XML can be compared with programming languages? Does it give you here something more than plain ASCII (except of possibility to validate the content using general tools)?

Petr Prikryl
Friday, November 23, 2001

I fear you're attacking a straw man in your remarks to me. I don't maintain anything in particular about XML, but was just tossing into the discussion an example where an interpreter was using XML files as input. The whole question of what is "really" a programming language is not terribly interesting to me.

Mike Gunderloy
Friday, November 23, 2001

Petr Prykl:
Right at the beginning I didn't compare XML to COBOL as programming languages I think you should read the words that are written not the ones you think have been written.

On the other hand to think that XML is just a character encoding scheme seems peverse (probably just as peverse as my treating it as a meta-language does to you).

Simon Lucy
Saturday, November 24, 2001

Hi. My apology for the attack to Mike.  This was not my intention ;-)  I see that Mike is rather on my side when showing the example of "a script".  I hope that I understand the meaning of "attacking a straw man", so I hope that that did not personally hurt you much ;-) -- English is not my first language.

For Simon, you are right that  you wrote about similar "positioning" of COBOL to the rest of the World and of XML to the rest of the World at the beginning of this discussion.  On the other hand, the words "processing" and explicit or implicit notices about "programming languages" (not necessarily yours) lead me to expressing that XML has no processing power.

I have never expressed the "perverted idea" ;-) that XML is just character encoding scheme.  As I wrote in the discussion on subject named "XML"...

XML adds some very important things to the ASCII:
1) There is no problem with character encoding and its interpretation.
2) It is possible to add explicitly the context of the information.
3) It is possible to describe explicitly the kind of the document.
4) It is possible to prescribe the rules for certain kind of document.
5) It is possible to verify if the document keeps the rules.
6) XML is not directly related to web documents, nor to the web-enabled applications.

... nor to anything like that -- as also ASCII files are not. I have approached the comparison of the importance of ASCII and XML from the Unix point of view.  As you may know, the ASCII streams are extremely important in Unix (together with pipe and redirection mechanisms) when you combine the functionality of standard utilities to get the desired result.

I fully agree with Simon's: "But in reality the complex is still complex."  There is nothing magical in XML itself.  It only generalized some of the problems that were repeatedly encountered in software solutions, and it set rules for how documents should be build and interpreted unambiguously.

P.S. I do not want to teach you; I want to make it clear also for myself.

P.P.S. What is the "CSV" in "XML is the CSV of the late 90s" as Jamie and Rodger noticed in Nov. 15?

Petr Prikryl
Tuesday, November 27, 2001

First, a minor lesson in English idiom. "Attacking a straw man" means that your statements were arguing against a point of view that I was not defending. The idea is that it's easy to win a battle if you get to make up your own opponent. There's no implication of a personal attack, and nothing that needs an apology.

On with the discussion. I think perhaps there's a useful distinction to be made between XML-as-it-should-be and XML-as-it-is. Yes, the formal XML standards do add those things that Petr mentions as being important advances over ASCII. Unfortunately, many of the XML documents I see don't encode characters properly, or don't validate, or have other problems.

CSV = Comma-Separated Values -- a common export format for programs from a few years ago.

Mike Gunderloy
Tuesday, November 27, 2001

*  Recent Topics

*  Fog Creek Home