Human and machine read differently. If you ignore that (in case with indentation), then why bother with writing human-friendly form of code, when what is going to be really executed is something else?
If anything, that sounds like an argument in favor of significant indentation, not against it. Humans and machines read differently, yes, which is why we tend to add whitespace and indentation to code even for programming languages where it’s not significant. We do that expressly because it makes the code more human-friendly, so it’s quite the opposite of ignoring their differences.
Because yaml is not a programming language, and debugging why your whatever you’re configuring isn’t working correctly can be a nightmare. It doesn’t tell you you missed an indent on a block, it just assumes it should be there and changes the meaning.
I think YAML has its fair share of design flaws, but I don’t think significant indentation is one of them. It may not be a programming language (which may be debatable), but there are plenty that use syntactic whitespace.
It’s not debatable… You linked to a programming language that uses yaml syntax, that didn’t make yaml itself a programming language… It’s not.
And I know there are plenty that use syntactic whitespace, and I hate that about all of them. Literally my only real frustration with python is due to the time of my life wasted debugging perfectly fine logic that fails because a few lines had incorrect indentation.
Just the other day I had a list show up as [“a”, “b”, “c”, “d”, “e”, false, “g”, “h”, “i”].
The issue was that, without me being overly aware of it, the data was going through a data -> yaml -> data step.
Yes, the data -> yaml filter was broken for not putting general strings in quotes. But IMO the yaml design invites these odd “rare” bugs.
I used to like yaml, but was happy to see Toml taking the niche of human-readable-JSON, but felt the format for nested key-value was a weird choice. However, I’ve always felt we could just have extended JSON a bit (allow line breaks, comments, if the outermost data type is an object, the curly brackets may be omitted).
Using YAML as an intermediate format between steps of a process is a mistake. I love YAML for configuration but I’d never use it for machine-to-machine anything. If the tool you’re feeding data to requires YAML as input, just give it JSON. All JSON is valid YAML.
Edit: I realize you weren’t the one who made that decision. I’m saying the problem isn’t YAML, the problem is someone using YAML inappropriately.
I completely agree with the general assessment, but then there are always pesky exceptions. In this case the list entered a JavaScript frontend from the yaml header of machine generated content pages for the website framework Hugo. And, of course, after finding the bug, it is clear that things could have been done differently and the issue easily avoided, but I also don’t think this was a completely unreasonable design. Since Hugo actually supports JSON headers (not just via the yaml parser, but thanks for that tip!), that was a quick fix. But I’m also somewhat amazed that it was possible for the strung-together fairly standard set of Python libraries (primarily pyyaml) to not get the strings properly quoted.
I like this. I also like yaml, I’ve had very few issues with it and it’s nicer to work with than json.
Json’s lack of support for trailing commas and comments makes it very annoying for everyday use.
Significant white-space is bullshit and i will die on this hill.
Is there space left on the hill? I want to join you.
I hear there’s significant space left
But it’s only white space. That’s kinda racist.
significant white space to it’s classist and racist
Their whole thing is that they don’t want to care about it, so if you get to the hill and there’s no space, you’re SOL.
Yeah I just want JSON with optionally quoted keys, and comments.
Commas (at least the trailing ones), comments, and nothing else. JSON with type inference seems like an incredibly bad idea…
JSON5 my beloved
You are not alone, my friend
Preach!
You’re going to indent your code anyway, so why not let the indentation carry meaning?
Because I am not counting white space when I read. Or should we just write machine code/assembler/pick something straight away?
Not sure I’m following the jump from significant whitespace to machine code. How are those related?
Human and machine read differently. If you ignore that (in case with indentation), then why bother with writing human-friendly form of code, when what is going to be really executed is something else?
If anything, that sounds like an argument in favor of significant indentation, not against it. Humans and machines read differently, yes, which is why we tend to add whitespace and indentation to code even for programming languages where it’s not significant. We do that expressly because it makes the code more human-friendly, so it’s quite the opposite of ignoring their differences.
No, it is an argument against it. We indent code so that it is more comfortable to read it, not in order to make it easier to understand
You’re mistaken:
Because yaml is not a programming language, and debugging why your whatever you’re configuring isn’t working correctly can be a nightmare. It doesn’t tell you you missed an indent on a block, it just assumes it should be there and changes the meaning.
Braces are visually clear.
I think YAML has its fair share of design flaws, but I don’t think significant indentation is one of them. It may not be a programming language (which may be debatable), but there are plenty that use syntactic whitespace.
It’s not debatable… You linked to a programming language that uses yaml syntax, that didn’t make yaml itself a programming language… It’s not.
And I know there are plenty that use syntactic whitespace, and I hate that about all of them. Literally my only real frustration with python is due to the time of my life wasted debugging perfectly fine logic that fails because a few lines had incorrect indentation.
Just the other day I had a list show up as [“a”, “b”, “c”, “d”, “e”, false, “g”, “h”, “i”].
The issue was that, without me being overly aware of it, the data was going through a data -> yaml -> data step.
Yes, the data -> yaml filter was broken for not putting general strings in quotes. But IMO the yaml design invites these odd “rare” bugs.
I used to like yaml, but was happy to see Toml taking the niche of human-readable-JSON, but felt the format for nested key-value was a weird choice. However, I’ve always felt we could just have extended JSON a bit (allow line breaks, comments, if the outermost data type is an object, the curly brackets may be omitted).
Using YAML as an intermediate format between steps of a process is a mistake. I love YAML for configuration but I’d never use it for machine-to-machine anything. If the tool you’re feeding data to requires YAML as input, just give it JSON. All JSON is valid YAML.
Edit: I realize you weren’t the one who made that decision. I’m saying the problem isn’t YAML, the problem is someone using YAML inappropriately.
I completely agree with the general assessment, but then there are always pesky exceptions. In this case the list entered a JavaScript frontend from the yaml header of machine generated content pages for the website framework Hugo. And, of course, after finding the bug, it is clear that things could have been done differently and the issue easily avoided, but I also don’t think this was a completely unreasonable design. Since Hugo actually supports JSON headers (not just via the yaml parser, but thanks for that tip!), that was a quick fix. But I’m also somewhat amazed that it was possible for the strung-together fairly standard set of Python libraries (primarily pyyaml) to not get the strings properly quoted.
Like the other person said, that’s not really YAML’s fault - just whoever decided to use YAML there.
If users aren’t intended to interact directly with the data, use JSON.