This article is weird. It wants to shoot against JSON, but then has to make half of its arguments against YAML instead. JSON has no "ambiguity in parsing", JSON has no indentation-based syntax, and JSON has no implicit typing to turn "no" into false.

XML "lost" because it is also a poor format for structured data. It requires constant choice between whether some content should be conveyed using attributes or child nodes. If you use child nodes, indentation may or may not be relevant (because it can introduce leading/trailing spaces). There is also no standard for data types. (Do you write a boolean attribute foo as foo="foo", foo="true", or foo="yes"? Sure, a schema can describe the allowed values, but whoever interprets the XML still needs to add the right translation to true and false in their programming language by hand, presumably.) Due to the manifold ways of expressing essentially the same data, working with XML is always painful.

This is not really XML's fault. It was designed as a way of marking up text. When that is your goal, XML is not a bad choice, and all of its features make a lot more sense. (For example, this child-attribute distinction: Is this part of the text? If so, it should be represented as child nodes. Otherwise, it should be an attribute.) Here, something like JSON really falls flat.

But most data is not marked up text. And yet, some people and institutions tried to push XML as the universal solution to all data transfer problems. This is the reason for the push-back against it.

This isn't to say that we did not also lose some things. In complex cases, having something like a schema is good. Comments are appreciated when the files are also read and edited by humans. JSON's data types are underspecified. But I firmly believe that the solution to this is not XML.

> This is the reason for the push-back against it.

Do you have evidence for that? From memory, it was basically because it was associated with the java/.net bloat from the early 2000s. Then ruby on rails came.

I assume that "all the different levels" might not exist yet. The author is probably creating them a bit in advance, and will keep going as long as they're motivated. Having a regular schedule for new releases helps, and doing it daily seems as sensible as any other schedule.

There is also the problem that they decided to make all references nullable, so `NullPointerException`s could appear everywhere. This "forced" them to introduce the escape hatch of `RuntimeException`, which of course was way overused immediately, normalizing it.

And here I was, thinking everybody already knew XKCD 1053 ...

But XML was designed as a markup language. That is was often used for configuration is not its fault. (And it works much better for its original purpose, where the otherwise strange distinction between attributes and child nodes actually makes sense.)

MAML seems to be designed as a configuration language, but calls itself a markup language. (YAML did too, but they changed it at some point.)

(Without knowing the precise nature of these laws) I would expect that they don't forbid you to store backups elsewhere. It's just that they mandate that certain types of data be backed up in sufficiently secure and independent locations. If you want to have an additional backup (or backups of data not covered by the law) in a more convenient location, you still can.

wild speculation and conjecture

Not wild.

When you live in Germany and are asked to send a FAX (and not a mail, please). Or a digital birth certificate is not accepted until you come with lawyers, or banks not willing to operate with Apple pay, just to name few..

Speculation, yes, but not at all wild

I'm German and in my 45 years of being so have never been required to send a fax. Snail mail yes, but never a fax.

Agree. It is based on my experience with German bureaucracy.

I generally agree that treating substrings that are numbers as numbers is a good default for most users in most situations.

However, for hex numbers this simply won't give good results because some of them will just happen to not contain any of the digits A to F and be treated as base-10 numbers by the heuristic while others will include these digits and be sorted differently.

(So, a having a strict lexicographic mode as an alternative in file managers would be nice.)

Dijkstra is right, of course. However, most math texts still use 1-based indexing. If you want to translate them into code, it's easier when the conventions match.

(Now, if you had a proposal for switching math over to 0-based indexing ...)

He (Dijkstra) even mentions this in the article:

> The above has been triggered by a recent incident, when, in an emotional outburst, one of my mathematical colleagues at the University —not a computing scientist— accused a number of younger computing scientists of "pedantry" because —as they do by habit— they started numbering at zero.

Good luck getting a community with literally hundreds of years of literature using 1 based indexing to change.

I did have one or two math professors who would use x_0 and x_1 instead of x_1 and x_2 when they had to name two objects.

But I have also seen places where 1-based indexing was used despite being "obviously wrong". I don't quite recall what it was, but there was sequence of objects A_1, A_2, ... and a natural way of combining A_k and A_l to get A_(k + l - 1). Had the indices been shifted by 1 to be 0-based, the result would have been A_(k + l), which would be much nicer to work with.

But the second interpretation only makes sense if the last item somehow deserves special treatment (over, say, the second-to-last item). Otherwise, you should similarly argue that the previous second-to-last item should also show up in the changes as it has now turned into the third-to-last item. (So maybe every item in the list should be preceded by as many spaces as are items before it and succeeded by as many commas as are items following it. Then, every change to the list will be a diff of the entire list.)

    first item,,,
     second item,,
      third item,
       fourth item

In my experience, special treatment for the last item is rarely warranted, so a trailing comma is a good default. If you want the last item to be special, put a comment on that line, saying that it should remain last. (Or better yet, find a better representation of your data that does not require this at all.)

> But the second interpretation only makes sense if the last item somehow deserves special treatment (over, say, the second-to-last item).

There do exist reasons why this can make sense:

- In an Algebraic Data Type implementation of a non-empty list, the last symbol is a different type constructor than the one to append an item to the front of an existing non-empty list (similarly how for an Algebraic Data Type implementation of an arbitrary list, the type constructor for an initial empty list is "special").

- In a single-linked list implementation, sometimes (depending on the implementation) the terminal element of the list is handled differently.

---

By the way: at work, because adding parameters at the beginning of a (parameter) list of a function is "special" (because in the code for many functions the first parameters serve a very special purpose), but adding some additional parameter at the end is not, we commonly use parameter lists formatted like

    'foo'
  , 'bar1'
  , 'bar2'
  , 'blub'

Last time I checked, Word was also basically untenable for math-heavy writing because there was too much procedure involved in setting a formula. This is fine if you need one here and there, but if you have lots of formulas (including many tiny ones, like just using the name of a variable), switching to a dedicated formula mode in the interface is just not pleasant. In LaTeX (or Typst), I just type $, and off I go.

Alt + = will put you in the equation editor fairly easily, and from there you can pretty much use LaTeX notation.

Even with a keyboard shortcut, I never found it to be truly satisfying. I cannot quite recall what was annoying, though. Maybe you cannot space back into the formula after closing it? (I certainly recall having the experience of typing a formula, closing it, noticing a mistake, hitting backspace, and deleting the entire formula.) Maybe there was just a slight delay for the formula editor to open? Also, $ is still more pleasant to type than Alt+=.

I would be willing to try again, but I'm not buying Word for the privilege.