[Verdex]

The quote that I heard (I think on HN) was, "If we had AIs to write XML for us then we never would have invented json."

My biggest LLM success resulted in something operationally correct but was something that I would never want to try to modify. The LLM also had an increasingly difficult time adding features.

Meanwhile my biggest 'manual' successes have resulted in something that was operationally correct, quick to modify, and refuses to compile if you mess anything up.

[zephen]

And a recent HN article had a bunch of comments lamenting that nobody ever uses XML any more, and talking about how much better it was than things like JSON.

The only thing I think I learned from some of those exchanges was that xslt adherents are approximately as vocal as lisp adherents.

[ern_ave]

> a recent HN article had a bunch of comments lamenting that nobody ever uses XML any more

I still use it from time to time for config files that a developer has to write. I find it easier to read that JSON, and it supports comments. Also, the distinction between attributes and children is often really nice to have. You can shoehorn that into JSON of course, but native XML does it better.

Obviously, I would never use it for data interchange (e.g. SOAP) anymore.

[zephen]

> Obviously, I would never use it for data interchange (e.g. SOAP) anymore.

Well, those comments were arguing about how it is the absolute best for data interchange.

> I still use it from time to time for config files that a developer has to write.

Even back when XML was still relatively hot, I recalled thinking that it solved a problem that a lot of developers didn't have.

Because if, for example, you're writing Python or Javascript or Perl, it is dead easy to have Python or Javascript or Perl also be your configuration file language.

I don't know what language you use, but 20 years ago, I viewed XML as a Java developer's band-aid.

[ern_ave]

> if, for example, you're writing Python or Javascript or Perl, it is dead easy to have Python or Javascript or Perl also be your configuration file language.

Sure. Like C header files. It's the easiest option - no arguments there.

But there are considerations beyond being easy. I think there's a case to be made that a config file should be data, not code.

[zephen]

Sure, it really depends on the use-case.

If people are really technical, then a language subset is fine.

If they're not really technical, then you might need a separate utility to manipulate the config file, and XML is OK if you need a separate utility. There are readers/writers available in every language, and it's human readable enough for debugging, but if a non-technical human mistakenly edits it, it might take some repair to make it usable again.

Even if you've decided on a separate config language, there are a lot of reasons why you might want to use something other than XML. The header/key/value system (e.g. the one that .gitconfig and a lot of /etc files use) remains popular.

I could be wrong, but it always seemed to me that XML was pushed as a doc/interchange format, and its use in config files was driven by "I already have this hammer and I know how to use it."

[abrahms]

This doesn't sound correct. We have computers write binary for us. We still make protocols which are optimizations for binary representation.. not because it's a pain to write.. but because there's some second order effect that we care about (storage / transfer costs, etc).