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.
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.
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.
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.
Significant white-space is bullshit and i will die on this hill.
Preach!
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
You are not alone, my friend
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.