Live data from Hacker News

Fear and Loathing in YAML

chrisshort.net

71–80 of 107 posts

Re: Fear and Loathing in YAML

#71

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.

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.

Re: Fear and Loathing in YAML

#72
post #67

We 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!

This might be the best pun I've ever read.

Re: Fear and Loathing in YAML

#73

Earlier 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.

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.

Re: Fear and Loathing in YAML

#74

Earlier 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

To explain the downvotes: JSON ⊆ YAML implies YAML ⊇ JSON. You're saying the equivalent of "3 > 1 is wrong: 1 < 3".

Re: Fear and Loathing in YAML

#75
post #39

Am 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.

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.

Re: Fear and Loathing in YAML

#76
post #39

Am 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…

Not me, I love YAML. I even write my content like blogs and such in raw YAML!

Re: Fear and Loathing in YAML

#77

Earlier 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 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

#78
post #39

Am 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…

Not alone, my preference goes to XML, and JSON second.

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

#79

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.

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.

Re: Fear and Loathing in YAML

#80

Earlier 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.

> 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.

Post reply on HN