Earlier quoted context omitted.
Significant whitespace seems like a good idea and looks great in small examples but it has some very serious downsides in real use. Being able to reliably reformat hundreds of lines of code with a single keypress is far more valuable than a few saved braces.
But it hasn’t hurt Python popularity.
Fear and Loathing in YAML
71–80 of 107 posts
Re: Fear and Loathing in YAML
#72We were editing a 2000 node Ant Config file by hand when the drugs began to take hold. I remember saying something like "I feel a bit lightheaded; maybe all configuration should be done in YAML from now on..."
We can't stop here. This is .BAT country!
Re: Fear and Loathing in YAML
#73Earlier quoted context omitted.
The problem is that in YAML, white space is significant. How is a formatted supposed to know: key1: value1 key2: value2 ...is supposed to be: key1: value1 key2: value2 ? How is it supposed to know if the first is actually what you meant to write? In grammars that aren’t white space dependent (such as JSON), it’s clear what this means: { "key1": "value1", "key2": "value2" }
Yes, in whitespace significant languages whitespace is significant. I could complain that my editor doesn't figure out how to fix all of my braces if I hit a button, after all I got the indentation right and can visually see the structure of my code should be correct no sweat.
Re: Fear and Loathing in YAML
#74Earlier quoted context omitted.
JSON is a subset of YAML, so if you want to write YAML like JSON you can, and you can even automatically convert from JSON style to more idiomatic YAML, or vice-versa, with appropriate tooling.
Correction: YAML is a superset of JSON
Re: Fear and Loathing in YAML
#75Am I the only one who finds YAML much harder to write than JSON or XML? It's not just the fact that I get the syntax for lists and maps confused all the damn time. The worst part is that I'm unable to use the keyboard shortcut for automatically formatting my document! I love that keyboard shortcut! I hate being without it! I'm certain it represents more than half of my key presses in other languages! I type a few cha…
JSON is a subset of YAML, so if you want to write YAML like JSON you can, and you can even automatically convert from JSON style to more idiomatic YAML, or vice-versa, with appropriate tooling.
Re: Fear and Loathing in YAML
#76Am I the only one who finds YAML much harder to write than JSON or XML? It's not just the fact that I get the syntax for lists and maps confused all the damn time. The worst part is that I'm unable to use the keyboard shortcut for automatically formatting my document! I love that keyboard shortcut! I hate being without it! I'm certain it represents more than half of my key presses in other languages! I type a few cha…
Re: Fear and Loathing in YAML
#77Earlier quoted context omitted.
JSON is a subset of YAML, so if you want to write YAML like JSON you can, and you can even automatically convert from JSON style to more idiomatic YAML, or vice-versa, with appropriate tooling.
That works if all your YAML authors are carefully avoiding any use of the features JSON can’t represent, like multiple documents, non-string map keys, and application-defined type tags.
That's true if you want round-trip conversion to and from JSON, but you don't need that for automated round-trip conversion between JSON-style (delimited, or, in the language of the YAML spec “flow style”) YAML and the somewhat more idiomatic for most uses indented, (or, in the spec language, “block style") YAML, e.g., if you find it easier to edit in flow-style but you are in an environment that wants the end product delivered in block style.
Notably, whitespace sensitivity is a feature of block style, but not flow style.
Re: Fear and Loathing in YAML
#78Am I the only one who finds YAML much harder to write than JSON or XML? It's not just the fact that I get the syntax for lists and maps confused all the damn time. The worst part is that I'm unable to use the keyboard shortcut for automatically formatting my document! I love that keyboard shortcut! I hate being without it! I'm certain it represents more than half of my key presses in other languages! I type a few cha…
So far I have been mostly YAML safe and will try to keep it that way, but it is getting hard when having to deal with k8s.
Re: Fear and Loathing in YAML
#79Earlier quoted context omitted.
Significant whitespace seems like a good idea and looks great in small examples but it has some very serious downsides in real use. Being able to reliably reformat hundreds of lines of code with a single keypress is far more valuable than a few saved braces.
But it hasn’t hurt Python popularity.
Re: Fear and Loathing in YAML
#80Earlier quoted context omitted.
The problem is that in YAML, white space is significant. How is a formatted supposed to know: key1: value1 key2: value2 ...is supposed to be: key1: value1 key2: value2 ? How is it supposed to know if the first is actually what you meant to write? In grammars that aren’t white space dependent (such as JSON), it’s clear what this means: { "key1": "value1", "key2": "value2" }
Significant whitespace seems like a good idea and looks great in small examples but it has some very serious downsides in real use. Being able to reliably reformat hundreds of lines of code with a single keypress is far more valuable than a few saved braces.
In some contexts, sure, which is one reason why YAML has two presentational styles with equal semantic power, between which a suitable tool can convert mechanically, and only one of those two styles features whitespace sensitivity.
> Being able to reliably reformat hundreds of lines of code with a single keypress is far more valuable than a few saved braces.
YAML gives you the ability to freely switch between a presentational style which provides the former and one which provides the latter, with no loss of semantic power, so it doesn't really matter which is better, since you don't have to choose between one and the other.