I can kind of understand it after having to work with an XML file where users encoded data into comments for no good reason. But yeah, it does make JSON awkward for lots of potential use-cases.
They’re not supposed to contain data, but some parsers will allow you to access what’s written into comments. And so, of course, someone made use of that and I had to extract what was encoded basically like that:
<!--
Host: toaster,
Location: moon,
--><data>Actual XML follows...</data>
My best guess is that they added this data into comments rather than child nodes or attributes, because they were worried some of the programs using this XML would not be able to handle an extension of the format.
In an ideal world, yes. In a locked down world where you have access only to 1/4 the codebase or your job is more ontology-focused, all you have access to might be the JSON. Leaving a comment or two about why a particular value or hierarchy is as it is is sometimes more clear than writing up a seperate README that no one will read
Almost all of those issues are solved by explicitly quoting your strings, the author even acknowledges that. Yeah it’s annoying that yaml lets you do otherwise, but the title is a bit dramatic.
I do agree there are plenty of annoyances that shouldn’t exist in YAML but do because someone had an opinionated belief at one point, though. For example, it shouldn’t try to guess that “yes”, “no”, “y”, and “n” are truthy values. Let the programmer handle that. If they write true/false, then go ahead and consider those truthy. Times can also be a bit of a pain - iirc writing 12:00 is supposed to be interpreted as 0.5 - but at least that’s something you can work around.
But there’s plenty in that article that are only problems because the writer made them problems. Every language lets you make mistakes, markup languages aren’t any different. It’s not a bad thing that you can write strings without quotes. It’s not forcing you to do so. Anchors also make it simple to reuse YAML and they’re completely optional. The issue with numbers (1.2 stays as 1.2 while 1.2.3 becomes "1.2.3" is very nitpicky. It’s completely reasonable for it to try to treat numbers as numbers where it can. If type conversion is that big of an issue for you, then I really doubt you know what you’re doing.
On top of all this, YAML is just a superset of JSON. You can literally just paste JSON into your YAML file and it’ll process it just fine.
I’m not saying it’s perfect, but if you want something that’s easy to read and write, even for people who aren’t techy, YAML is probably the best option.
Coming from powershell scripting, every string is put in quotes and to be printed strings with variables are put in $($var) (e.g. Write-Host "Example-Issue: $($IssueVariable)")
Saves me the trouble of hoping that $($IssueVariable) isnt interpreted as a string by PowerShell.
Time to read this if you haven’t already
https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell
See, this is why we can’t have nice things.
I can kind of understand it after having to work with an XML file where users encoded data into comments for no good reason. But yeah, it does make JSON awkward for lots of potential use-cases.
Anything can be abused. That’s not a legitimate reason to take away perfectly reasonable features. Looking at you, Java (unsigned integers).
Hm? Comments are not data.
They’re not supposed to contain data, but some parsers will allow you to access what’s written into comments. And so, of course, someone made use of that and I had to extract what was encoded basically like that:
<!-- Host: toaster, Location: moon, --> <data>Actual XML follows...</data>My best guess is that they added this data into comments rather than child nodes or attributes, because they were worried some of the programs using this XML would not be able to handle an extension of the format.
They are useful metadata important to the longterm lifespan of the codebase
That’s why they make sense in code and config files. JSON is neither, despite the insistence of far too many people to write configuration in it.
In an ideal world, yes. In a locked down world where you have access only to 1/4 the codebase or your job is more ontology-focused, all you have access to might be the JSON. Leaving a comment or two about why a particular value or hierarchy is as it is is sometimes more clear than writing up a seperate README that no one will read
This would undoubtedly, unquestionably happen, and it would break JSON. The only reason it works so well is because comments aren’t allowed.
As if I didn’t hate the format enough before
Iceland mentioned 🇮🇸
Almost all of those issues are solved by explicitly quoting your strings, the author even acknowledges that. Yeah it’s annoying that yaml lets you do otherwise, but the title is a bit dramatic.
Or by configuring your parser.
I do agree there are plenty of annoyances that shouldn’t exist in YAML but do because someone had an opinionated belief at one point, though. For example, it shouldn’t try to guess that “yes”, “no”, “y”, and “n” are truthy values. Let the programmer handle that. If they write true/false, then go ahead and consider those truthy. Times can also be a bit of a pain - iirc writing
12:00is supposed to be interpreted as 0.5 - but at least that’s something you can work around.But there’s plenty in that article that are only problems because the writer made them problems. Every language lets you make mistakes, markup languages aren’t any different. It’s not a bad thing that you can write strings without quotes. It’s not forcing you to do so. Anchors also make it simple to reuse YAML and they’re completely optional. The issue with numbers (
1.2stays as1.2while1.2.3becomes"1.2.3"is very nitpicky. It’s completely reasonable for it to try to treat numbers as numbers where it can. If type conversion is that big of an issue for you, then I really doubt you know what you’re doing.On top of all this, YAML is just a superset of JSON. You can literally just paste JSON into your YAML file and it’ll process it just fine.
I’m not saying it’s perfect, but if you want something that’s easy to read and write, even for people who aren’t techy, YAML is probably the best option.
Coming from powershell scripting, every string is put in quotes and to be printed strings with variables are put in
$($var)(e.g.Write-Host "Example-Issue: $($IssueVariable)")Saves me the trouble of hoping that
$($IssueVariable)isnt interpreted as a string by PowerShell.