I loved YAML until I read the spec, and now I dislike most of YAML beyond the basics and avoid it unless "ease of humans to edit" is a primary goal.

I think our industry's distraction with config file formats is due to trying to find a reasonable balance between human readable and machine readable. XML was great for machines, YAML is OK for humans, JSON/TOML are somewhere in the middle.

>Does this dude not understand what a data serialization format is, yet is trying to tell people how to design applications?

"Data serialization format" is irrelevant, both XML and YAML are designed for this.

It's just that XML was just over-designed (with all the auxilliary specs), and YAML was designed badly from the start, even for mere configuration.

If someone thinks the refuted his points or preference because they "understand what a data serialization format is", they are really not understand XML/YAML and the domains they're actually used.

YAML wasn't designed for configuration, and XML wasn't designed for data serialization.

Both were designed for both.

SGML might not have been designed for data serialization (it was designed for document authoring), but the XML standard committees and company representatives were heavily interested in generic data serialization.

And YAML was also designed for human readable editing and serialization of configuration among other data serialization needs. "Configuration files" is literally the first use case for it mentioned in the standard's homepage:

"Even though its potential is virtually boundless, YAML was specifically created to work well for common use cases such as: configuration files, log files, interprocess messaging, cross-langauge data sharing, object persistence and debugging of complex data structures".

But the point is moot. What each language was "designed for" is irrelevant to what it's predominantly used for throughtout the industry.

People found a use for them, regardless of whether their designers might or might not foreseen it (they had), and for this use which is what interests people, there are certain issues.

If the answer was as easy as "just use a language better designed for that use case and it will solve your issues", they would have done it already.

Some have their hands tied because vendors/projects/etc they use, enforce TOML or YAML or XML and have to use them too to work with them. Others find alternatives worses for their use case, but still don't consider the one they use (TOML/YAML/XML/etc) as optimal.