4 ms·

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: v

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" }

dragonwriter 6y ago
{ "key1": values, “key2”: value2 } is valid YAML with the same sematics as it has in JSON; if you have a YAML-aware editor (or editor mode) it will probably format that just as easily as in JSON.
cageface 6y ago
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.
- goatlover 6y ago
  But it hasn’t hurt Python popularity.
  - bobbylarrybobby 6y ago
    Personally it’s one of reasons I’m using python less and less and JavaScript more and more. I just can’t stand the white space.
    - dragonwriter 6y ago
      The difference between Python and YAML is that Python doesn't have a semantically-equivalent, non-indentation-sensitive presentation style. How you choose to view and work with YAML is a choice that doesn't need to have any impact on what you share with others and how they choose to view and work with it. While I'm not usually fond of “you're holding it wrong” arguments, that's pretty much the proper response to complaints about YAML’s indentation sensitivity, since you can work with YAML in a style which isn't indentation sensitive without anyone you share data with seeing anything different.
  - cageface 6y ago
    It's possible that Python might be more popular than it is without this feature. It's certainly one of the main reasons I avoid it.
  - acdha 6y ago
    Python’s grammar is well defined and has far more validation. YAML has multiple ways to define the same output and since it makes almost anything legal there’s not a way for a tool to disambiguate. For example, if you double-indent something, YAML will just silently assume you wanted a nested data structure but Python will throw an indentation error. That causes issues in many editors when copy-and-pasting. That pattern continues where Python uses indentation to force clarity and consistency but still has syntax which removes ambiguity. A key one is that Python requires quoting data, avoiding all of the common data loss in YAML when people happen to enter data with meaning in YAML (country=no, names with equal signs or colons, etc.), and you have to open and close structures with syntax rather than just indentation. The most analogous Python bug is when a statement immediately after an if, nested def, etc. is one level of indentation than intended. That definitely happens but a fair fraction of the time it’s immediately obvious because it usually fails due to something like a variable not being in scope. YAML consumers are more likely to ignore extra elements so it’s easier to miss things like that for a while unless you have an unusually strict validation stage.
- dragonwriter 6y ago
  > Significant whitespace seems like a good idea and looks great in small examples but it has some very serious downsides in real use. 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.
  - cageface 6y ago
    If Python & Haskell had this I'd be more inclined to use both of them.
    - dragonwriter 6y ago
      > If Python & Haskell had this I'd be more inclined to use both of them. Haskell does. https://en.m.wikibooks.org/wiki/Haskell/Indentation https://en.m.wikibooks.org/wiki/Haskell/Indentation
otterlicious 6y ago
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.
- bobbylarrybobby 6y ago
  The issue is that in practice it’s quite difficult to reliably get whitespace correct all of the time, whereas braces seem quite easy to get right. If you’ve ever tried cutting and pasting a code block in python you know the pain of having to manually fix whitespace. The same operation in a brace-delimited language has a much smaller chance of going wrong, as the only thing you need to get right is the endpoints of the cut selection.
wodenokoto 6y ago
If you write { "key1": "value1", "key2": "value2" } without the commas, you're also on your own when it comes to fixing it. You just type [enter] instead of [space] between "value1" and "key2:" in your original example to get correct indentation.

dragonwriter 6y ago

{ "key1": values, “key2”: value2 } is valid YAML with the same sematics as it has in JSON; if you have a YAML-aware editor (or editor mode) it will probably format that just as easily as in JSON.

cageface 6y ago

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.

goatlover 6y ago
But it hasn’t hurt Python popularity.
- bobbylarrybobby 6y ago
  Personally it’s one of reasons I’m using python less and less and JavaScript more and more. I just can’t stand the white space.
  - dragonwriter 6y ago
    The difference between Python and YAML is that Python doesn't have a semantically-equivalent, non-indentation-sensitive presentation style. How you choose to view and work with YAML is a choice that doesn't need to have any impact on what you share with others and how they choose to view and work with it. While I'm not usually fond of “you're holding it wrong” arguments, that's pretty much the proper response to complaints about YAML’s indentation sensitivity, since you can work with YAML in a style which isn't indentation sensitive without anyone you share data with seeing anything different.
- cageface 6y ago
  It's possible that Python might be more popular than it is without this feature. It's certainly one of the main reasons I avoid it.
- acdha 6y ago
  Python’s grammar is well defined and has far more validation. YAML has multiple ways to define the same output and since it makes almost anything legal there’s not a way for a tool to disambiguate. For example, if you double-indent something, YAML will just silently assume you wanted a nested data structure but Python will throw an indentation error. That causes issues in many editors when copy-and-pasting. That pattern continues where Python uses indentation to force clarity and consistency but still has syntax which removes ambiguity. A key one is that Python requires quoting data, avoiding all of the common data loss in YAML when people happen to enter data with meaning in YAML (country=no, names with equal signs or colons, etc.), and you have to open and close structures with syntax rather than just indentation. The most analogous Python bug is when a statement immediately after an if, nested def, etc. is one level of indentation than intended. That definitely happens but a fair fraction of the time it’s immediately obvious because it usually fails due to something like a variable not being in scope. YAML consumers are more likely to ignore extra elements so it’s easier to miss things like that for a while unless you have an unusually strict validation stage.
dragonwriter 6y ago
> Significant whitespace seems like a good idea and looks great in small examples but it has some very serious downsides in real use. 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.
- cageface 6y ago
  If Python & Haskell had this I'd be more inclined to use both of them.
  - dragonwriter 6y ago
    > If Python & Haskell had this I'd be more inclined to use both of them. Haskell does. https://en.m.wikibooks.org/wiki/Haskell/Indentation https://en.m.wikibooks.org/wiki/Haskell/Indentation

otterlicious 6y ago

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.

bobbylarrybobby 6y ago
The issue is that in practice it’s quite difficult to reliably get whitespace correct all of the time, whereas braces seem quite easy to get right. If you’ve ever tried cutting and pasting a code block in python you know the pain of having to manually fix whitespace. The same operation in a brace-delimited language has a much smaller chance of going wrong, as the only thing you need to get right is the endpoints of the cut selection.

wodenokoto 6y ago

If you write { "key1": "value1", "key2": "value2" } without the commas, you're also on your own when it comes to fixing it. You just type [enter] instead of [space] between "value1" and "key2:" in your original example to get correct indentation.