Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fear and Loathing in YAML

chrisshort.net

Post reply on HN
Print view View original

51–60 of 107 posts

Re: Fear and Loathing in YAML

#51

Post by colejohnson66 »

andybak wrote: post #42
tofflos wrote: 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…

My keyboard shortcut for automatically formatting my documents usually understand the document format or programming language I'm using. If it doesn't then I'm using the wrong editor.

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

Re: Fear and Loathing in YAML

#52

Post by dragonwriter »

tofflos wrote: 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.

Re: Fear and Loathing in YAML

#53

Post by cageface »

colejohnson66 wrote: post #51
andybak wrote: post #42

Earlier quoted context omitted.

My keyboard shortcut for automatically formatting my documents usually understand the document format or programming language I'm using. If it doesn't then I'm using the wrong editor.

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.

Re: Fear and Loathing in YAML

#54

Post by hombre_fatal »

Arnavion wrote: post #36
samatman wrote: post #6

TOML remains severely underrated, for some reason. It's easy to read, easy to write, trivial to map onto JSON, and refreshingly clear of footguns. There are comments! If you get to pick your format for a configuration language, start by trying to talk yourself out of TOML. You'll probably fail; I'm interested to hear if folks out there have examples of something TOML is bad at, because I didn't come up with any when…

I like TOML too, but speaking of footguns, there is one where it comes to serialization. If you have something like: struct Foo { int bar; Baz baz; int quux; } ... you can't naively serialize this like: [foo] bar = 5 [foo.baz] ... quux = 6 because that makes `quux` a property of `foo.baz`, not of `foo`. The serializer has to be smart enough to recognize that primitive fields have to be serialized before object fields…

Yeah, I never liked how in TOML once you start a [table], you can never go back to the top level, just start more [tables].

What it means in practice is that if you want to use [table] syntax because it's more readable for this one key, you have to move it to the very end, away from the keys it was related to.

Wasn't impressed.

Re: Fear and Loathing in YAML

#55

Post by otterlicious »

colejohnson66 wrote: post #51
andybak wrote: post #42

Earlier quoted context omitted.

My keyboard shortcut for automatically formatting my documents usually understand the document format or programming language I'm using. If it doesn't then I'm using the wrong editor.

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

#56

Post by dragonwriter »

colejohnson66 wrote: post #51
andybak wrote: post #42

Earlier quoted context omitted.

My keyboard shortcut for automatically formatting my documents usually understand the document format or programming language I'm using. If it doesn't then I'm using the wrong editor.

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

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

Re: Fear and Loathing in YAML

#57

Post by andreareina »

samatman wrote: post #25
ben509 wrote: post #13

Earlier quoted context omitted.

Another comment brought up StrictYAML, and they have a good dissection of the problems with TOML[1]. Personally, after doing a few pyproject.toml files, I still find it confusing and awkward as soon as you get past simple headers and key-values. TOML is like YAML, it translates to "jsonic" types, but JSON's virtue is that simple 1:1 mapping between syntax and data. TOML and YAML both have non-obvious syntax and there…

That's not a bad argument against using TOML, and I'm inclined to agree that TOML is more verbose than it has to be for heavily-nested maps-of-maps-of-maps. Which you can pretend is a strength, since I consider doing that an anti-pattern. But it is a valid critique. However, the TOML they offer as a comparison to the StrictYAML is probably auto-generated (they do say "serialized TOML equivalent") and it's quite a bit…

> TOML deliberately has a couple of ways of writing arrays, and a one-line short format for maps: you're supposed to alternate these, and this technique could eliminate most of the repetition in that particular file.

Could you provide an example of what you mean, or point to some such? We're having a spot of trouble with arrays of maps ourselves.

Re: Fear and Loathing in YAML

#58

Post by dnautics »

samatman wrote: post #6

TOML remains severely underrated, for some reason. It's easy to read, easy to write, trivial to map onto JSON, and refreshingly clear of footguns. There are comments! If you get to pick your format for a configuration language, start by trying to talk yourself out of TOML. You'll probably fail; I'm interested to hear if folks out there have examples of something TOML is bad at, because I didn't come up with any when…

I love toml and used it extensively, but there are definitely warts. Arrays of objects are particularly painful[0]. If you decide that a first-level singleton non-object parameter semantically belongs after a first-level object parameter, you can't do it. Which is kind of no-duh, but TOML is simple enough that you might forget that you can't do that

[0] i mean this:

    [[abc]]
      param="foo"

    [[abc]]
      param="bar"

    [[abc]] 
      param="baz"
Edit: ok, just read the sibling comments and they totally echo my gripes. So there's something about our common issues.

Re: Fear and Loathing in YAML

#59

Post by davidpires »

TheSwordsman wrote: post #35

I think I would genuinely be pretty happy with a well-supported extension of the JSON spec that allows comments. Even if it required an explicit start and end of the comment (/* ... */). I also can't say I want or need anchors/references from YAML, so I think that helps me be quite OK with using JSON. I appreciate the challenges of writing JSON, but also think it can be easier to spot issues if you have an editor tha…

If you are using JavaScript you can use jsonc [0] it's exactly that just JSON with comments. VSCode and typescript config files already use it by default

https://github.com/microsoft/node-jsonc-parser

Re: Fear and Loathing in YAML

#60

Post by [deleted] »

dnautics wrote: post #58
samatman wrote: post #6

TOML remains severely underrated, for some reason. It's easy to read, easy to write, trivial to map onto JSON, and refreshingly clear of footguns. There are comments! If you get to pick your format for a configuration language, start by trying to talk yourself out of TOML. You'll probably fail; I'm interested to hear if folks out there have examples of something TOML is bad at, because I didn't come up with any when…

I love toml and used it extensively, but there are definitely warts. Arrays of objects are particularly painful[0]. If you decide that a first-level singleton non-object parameter semantically belongs after a first-level object parameter, you can't do it. Which is kind of no-duh, but TOML is simple enough that you might forget that you can't do that [0] i mean this: [[abc]] param="foo" [[abc]] param="bar" [[abc]] par…

[deleted]
Post reply on HN