

Linus Torvalds is wrong about XML - Sami_Lehtinen
http://www.kidstrythisathome.com/2014/03/why-linus-torvalds-is-wrong-about-xml/

======
beagle3
Article author is very wrong, Linus isn't.

If 99% of XML uses make a bad name for the rest of them, the problem is with
XML. "XML" is not a spec - it's a culture, and the culture is rotten, and
Linux calls it out. Even if there's the occasional good use of XML, it pales
among all the other horrible uses -- and every rare good use of XML is not
actually better than the alternatives.

Author blames Linus for using "m" to signify "meter" instead of "miles" as
being incomplete. Well, every nontrivial important measure is in MKS, in which
"m" is properly distinguished from "mm", "cm", "km". (And by the way, did the
post mean nautical miles, or ground miles?)

~~~
ygra
I agree that confusing miles and meters is probably hard, especially to people
exposed to a sane measurement system. However, his point about durating being
represented in a non-standard format is a valid one. Also I'm very confused
why temperatures are given in Coulomb.

~~~
beagle3
> However, his point about durating being represented in a non-standard format
> is a valid one.

ISO 8601 does specify a standard for duration. I've only ever seen it used in
vCalendar entries - I've seen DD:HH:MM:SS everywhere else. So while it is an
ISO standard, much like OOXML, almost no one actually uses it - in which case
I wouldn't be hard on Linus for not using it.

> Also I'm very confused why temperatures are given in Coulomb.

Me too, but it's still more sane than giving them in Farad like some people do
:)

~~~
userulluipeste
"So while it is an ISO standard, much like OOXML, almost no one actually uses
it..."

That should be a subject of education. I never new about that ISO 8601 until I
seen an xkcd caricature, whereas I should have known only that standard
notation in my education!

------
arocks
It is funny that he says that the problem with XML is bad programmers because
the first design goal of XML[1] was -

"XML shall be straightforwardly usable over the Internet."

The bewildering number of XML specifications to simply use an XML file makes
it daunting for anyone to learn to use XML "properly". The XML standard today
is hardly anything but "straightforward".

Additionally, it is not a particularly efficient format for machines nor for
humans to use. Saying that a good editor can solve everything is a very
flippant way of addressing the common challenges with editing maze-like XML
documents.

Perhaps Linus didn't elaborate on the context of his criticism for the XML
format, but it resonated with a lot of programmers not because of his
popularity but they had faced similar painful situations before.

[1]: [http://www.w3.org/TR/REC-xml/](http://www.w3.org/TR/REC-xml/)

------
LaSombra
The article says "XML files should standalone". Most XML files are not readily
readable unless you have looked at the XSD or copious amounts of
documentation, if someone documented it, to understand the options, their
meaning and their values. And, usually, XSDs are referred as schemas, just
saying.

Subsurface XML's are, to me at least, reasonable. Does it follow a spec? No.
Can I, a human, look at it and say that 'm' stands for meters? Sure, the
context is "humans diving" so 'm' can stand for miles. Being a human means I
can process contextualized information.

Man, I really hate XML and have some dislike for its defenders.

------
LaSombra
I work with Java application servers and I loathe XML. Why Ant uses an XML?
Why couldn't it be a simple DSL? <copy to=...>" is not needed, really.

Property files go a long way to help differentiate it. XML has invaded almost
all aspects of Java programming, but it seems things are getting better with
Java EE 6 and the web services annotations for example, but application
servers and framework authors need to stop cramming XML this and XML that for
configuration files.

This needs to stop.

------
forgottenpass
I don't get why this was written. Linus said something obviously hyperbolic
about a language with many generally accepted pitfalls. This author clarifies
that it isn't impossible to work with, has some applications and that using it
well is better than using it poorly.

What I'm trying to say is: is this just making a general and well-worn case
for XML or is there a point relevant to Subsurface? I'm sure I could find a
shallow remark made by this author and write 1000 words of qualification
around that too. Right now, all I see is someone responding to a statement
from a big name for attention.

Is there a argument hidden in there about XML's relative ease to work with
compared to other formats, either programatically or as a user? Any points on
if XML is the right or wrong choice of tool for subsurface?

The closest thing I see is a throwaway comment about an instance where CSV
files also benefit from editors with features supporting more than plain text.
And a point about unit type specification irrelevant to the file format.

------
renox
Not very convincing. 1) if you need an IDE to write comfortably XML that's a
sign that it _isn 't_ a good format for men. 2) as for computers, it isn't a
very good format either: the schema's syntax comes to mind..

------
__pThrow
I've never understood what problem XML solves.

Does XML make a file understandable by a developer in superior ways to other
formats? Not especially.

Does the use of XML make error recovery from a partially borked file possible?
Not really.

What problem is actually solved by XML (that other formats don't also "solve"
... and better?)

~~~
dykesa
I am a database guy. Typically I'm against XML (especially in a database)
however, I have a scenario where there is a test system and there are some
standard bits of information (test description, stats, etc.) that all the
tests have but they all come out in a different structure meaning: I have 4500
queries that test different aspects of our data-set and they all come out with
different columns.

They have different columns because it deals with about 600 different tables
and the output is what is relevant to the test. I have decided that in this
instance, I want to capture all of the results in a single table so that they
are centralized. XML solves this issue for me. I can grab the results in XML,
and insert them into a centralized table where they can be reviewed later.

TL;DR XML can solve some data structure issues where you don't always know the
final output until it shows up.

------
lutusp
The link in the linked article that is meant to link to the evidence that
Torvalds is wrong, instead links to itself. Inadvertent self-reference in a
conversation about modern data structures is a very bad sign.

~~~
chalst
The first comment is the echo of the author posting to Twitter at
[https://twitter.com/legostormtroopr/status/44287331642916044...](https://twitter.com/legostormtroopr/status/442873316429160448)
\- it isn't part of the article itself.

------
shanehou
I'm waiting for Linus' response, which will definitely make the author cry and
regret for what he had said.

