XML is ok for complex docs where you have a detailed structure and relationships. JSON is good for simple objects. YAML is good for being something to switch to for the illusion of progress.
It’s got enough serious flaws and quirks that I can feel smug hating on it. JSON is far from perfect, but overall it’s the least worst of human-readable formats.
Only Python manages to get away with syntactical indentation.
The complaints about yaml’s quirks (no evaluating to false, implicit strings, weird number formats, etc.) are valid in theory but I’ve never encountered them causing any real-life issues.
no doesn’t become false, it becomes Norway, and when converted to a boolean, Norway is true. The reason’s because one on YAML’s native types is an ISO country code enum, and if you tell a compliant YAML implementation to load a file without giving it a schema, that type has higher priority than string. If you then call a function that converts from native type to string, it expands the country code to the country name, and a function that coerces to boolean makes country codes true.This paragraph was wrong. The other paragraphs are unaffected.
The problem’s easy to avoid, though. You can just specify a schema, or use a function that grabs a string/bool directly instead of going via the assumed type first.
The real problem with YAML is how many implementations are a long way from being conformant, and load things differently to each other, but that situation’s been improving.
Are you sure? I’ve always heard it the other way around and a quick search for "YAML norway’ gives this
The reason to why this is problematic in some cases, is “The Norway Problem” YAML has: when you abbreviate Norway to its ISO 3166-1 ALPHA-2 form NO, YAML will return false when parsing it
Also, YAML 1.2 (2009) changed the format of booleans to only be case insensitive true and false. “No” no longer is false if you’re parsing as a version 1.2 document.
Yeah, looks like I’d remembered it backwards. It’s still an easily solvable problem by not using a load everything as whatever type you feel like function.
Idk, I never used the weird advanced features of YAML, but the basics seems really nice for stuff you want people, especially non programmers, to edit. I generally default to YAML for config files.
How does one address the paradox that, as JSON itself is evil, one cannot use it for evil?
(opinions may vary on the above; but it’s mine, so nyah nyah.)
It’s less evil than XML or YAML
XML is ok for complex docs where you have a detailed structure and relationships. JSON is good for simple objects. YAML is good for being something to switch to for the illusion of progress.
It’s still using the lesser of 3 evils, we need a fourth human readable data interchange format.
"Problem: There are
34 standardsObligatory xkcd
>TOML has entered the channel
Any human-readable format compatible with JSON is inevitably going to be used as an interchange format…
The lesser of what?
YAML is (mostly) a superset of JSON. Is the face hugger any less evil than the alien bursting out of your chest?
It’s got enough serious flaws and quirks that I can feel smug hating on it. JSON is far from perfect, but overall it’s the least worst of human-readable formats.
Only Python manages to get away with syntactical indentation.
The complaints about yaml’s quirks (
noevaluating tofalse, implicit strings, weird number formats, etc.) are valid in theory but I’ve never encountered them causing any real-life issues.nodoesn’t becomefalse, it becomesNorway, and when converted to a boolean, Norway is true. The reason’s because one on YAML’s native types is an ISO country code enum, and if you tell a compliant YAML implementation to load a file without giving it a schema, that type has higher priority than string. If you then call a function that converts from native type to string, it expands the country code to the country name, and a function that coerces to boolean makes country codes true.The problem’s easy to avoid, though. You can just specify a schema, or use a function that grabs a string/bool directly instead of going via the assumed type first.
The real problem with YAML is how many implementations are a long way from being conformant, and load things differently to each other, but that situation’s been improving.
Are you sure? I’ve always heard it the other way around and a quick search for "YAML norway’ gives this
Also, YAML 1.2 (2009) changed the format of booleans to only be case insensitive true and false. “No” no longer is false if you’re parsing as a version 1.2 document.
Yeah, looks like I’d remembered it backwards. It’s still an easily solvable problem by not using a load everything as whatever type you feel like function.
That is somehow so much worse
I believe they’re getting themselves confused.
nowas false prior to YAML 1.2. This is known as the “Norway problem.”YAML is evil.
Hmm, hard to argue with that :P
Idk, I never used the weird advanced features of YAML, but the basics seems really nice for stuff you want people, especially non programmers, to edit. I generally default to YAML for config files.