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.
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.
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..
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)
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.
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.