I'm not criticizing having attributes-vs-child-elements. The problem with XML is not that it exists or that it is a particularly badly designed markup language.

The problem is that XML is ill-suited for configuration files.

Yeah JSX and especially TSX would be quite nice. YAML though can’t die soon enough.

You think that JSX would be suited for configuration files?

Why?

I don't understand your comment.

Because people reinvent half of it, different half every time in each project, and call it 'configuration' which somehow gives them licencia poetica for whatever crazy dung they come up with.

Compare ansible vs helm vs github actions vs literally anything with nontrivial config.

Note that if you asked me for real, I'd be a dhall proponent, but most normal people look at me funny the first time they hear it and then the second time they see the syntax.

dhall looks nice actually! Thanks for elaborating :)

Why? I can store it in version control. I can validate if the file has syntax errors or schema errors etc. etc. With a proper platform it's easy to generate or parse. It allows for both hierarchical structures (looking at you .ini). The only downside might be that you need a larger library to parse it. But i probably encounter xml somewhere along the line anyway due to interactions with a 3rd party system, so that point is moot.

You have a low bar for config languages. I'd also like one to not be overly verbose, not be clearly intended for markup instead of object storage and not have security issues until you configure the parser just right (though that's often not an issue with configs). XML fails all of these, and YAML isn't much better.

If we're limiting ourselves to just JSON, INI, XML and YAML as potential choices, I get why people cling onto one of these suboptimal choices and then fiercely defend it, but there are other options. There's libconfig, JSON5, Dhall, various interpreted languages...

Sadly these alternatives are far from mainstream and have no support in standard libraries, so I think most developers will continue to pick whichever common option's issues they can deal with.

I'd like my config files to have two words in it "do it" and for it to just know what I want.

But at the end of the day that's not possible because reality intrudes. You give up a lot for that lack of verbosity, not everyone will agree that it's a worthy tradeoff.

It's a noble goal to want a simple configuration format, toml is far from the simplest, line separated options format is simpler. The fact that it needs a parser indicates that it creates a bigger parsing problem than necessary.

> And, on that note, I think that if I could pick as single thing that irritates me the most about YAML, it's that it isn't actually a ML.

“YAML ain't markup language” is kinda the whole point.

For a full year it stood for "Yet Another Markup Language".

First draft: https://yaml.org/spec/history/2001-03-30.html

Last draft calling it that: https://yaml.org/spec/history/2001-12-10.html

First draft with the new acronym: https://yaml.org/spec/history/2002-04-07.html

It's also funny that the file extension YML is the successor of XML, so the rest is probably a backronym from that.

Wouldn't the successor of XML be XMM?

Next you'll be telling me Beyonce's sisters should be named Beyoncd and Beyoncf instead of Aeyonce and Ceyonce.

Feyonce can’t get anyone to believe she’s married and Vakira’s has astonishingly honest hips

Judging from BCPL, the successor should just be Y.

The file extensions for yaml is .yaml, .yml is the alternative because of legacy 8.3 systems.

The thing is if you're using it as configuration language, object notation is correct, not markup.

I'm curious why you think that is? Especially since you are likely to want to style the configuration for display to the user in many cases, having it be a document makes a lot of sense.

That is, if the value is something you would expect to be able to show to a user, then it probably shouldn't be at attribute. If it is a value that changes how you would show it, then attribute makes a lot more sense.

I also think a strong adherence to any preference between attribute and markup is a touch too dogmatic. The only real distinction at the language level is if you allow children, or not. If it can have children, it pretty much has to be a child and not an attribute.

Ok forget the difference between attribute and markup. What is the "right" way to think of this:

    <foo>
      <bar>1</bar>
      <bar>2</bar>
      <baz>3</baz>
      <baz>4</baz>
    </foo>

Why do you think there is a "right" way?