Hacker News Reader

Comment by seiferteric | Hacker News Reader

YAML is better for this.

JSON has an advantage of not having significant whitespace: a bit more verbose with the { and [, but I'd argue it is more robust for complex configuration.

YAML feels to me like the creation of a person who has never fought with a makefile that imported another makefile that had an extra tab on line 9432: not quite true hell, but a few hours of trying to figure out WHY things aren't working right you would be hard pressed to tell the difference.

How is "no whitespace" an advantage for a human readable file format? You could write JSON with zero whitespace, but you wouldn't because whitespace is absolutely necessary for human comprehensibility.

Because humans make stupid accidental mistakes.

YAML says there's a world of difference between

    - flag1
    - option2

and

    -flag1
    -option2

but for a human who just wants their thing to work, that's inscrutable, but in JSON, they become

    [
        "flag1", 
        "config2"
    ]

and

    "-flag1 -config2"

respectively.

Personally, live python as config is my preference, followed by YAML because comments, but YAML isn't perfect.

If the options are right next to each other it's clear there's a misalignment:

    - option1
     -option2

won't work, but

     - option1

# if there is a huge explanatory

# multi-line comment

# as is sometimes seen in config

# files, sometimes it can be hard

# to see the misalignment.

      - option2

As @rockostrich and @fragmede pointed out, I'm talking about whitespace having parsing impact ("significant whitespace"), not just any whitespace. The fact that extra spaces changes the structure of the output seems like a total minefield to me, unless your config is being machine generated (in which case there are many more robust formats to choose).

No significant whitespace you say? Take a peek at this: https://paste.ofcode.org/n9q3dnDcPDK5KLex54z6uw

By "significant", fomojola meant whitespace does not affect parsing. That JSON you linked to could be minified into a single line with 0 whitespace and still be parsed.

I have a project with fairly complex YAML config files.

YAML quickly gets cranky and brittle, there are too many ways to do everything, and it's very challenging to easily debug some of the syntax errors. If I had to do it over again, I'd probably go with json over yaml.

With JSON, I can have my text editor do the validation before I even save. That kind of tooling just doesn't exist for YAML.

Completely agreed. For me, writing YAML always feels like a guessing game.

When I first encountered an ESLint config written in YAML, for example, it took me like a dozen tries (no exaggeration) to successfully convert a

    [2, "always"]

type value into a more advanced

    [2, { "options": blah, "foo": bar }]

value. The ways that intuitively seemed like they definitely should have worked, didn't work, and I consider myself a competent programmer.

I came to dislike it even more once I found out it had features like &anchors, <<:, etc. Not only do I find the syntax repulsive, but having custom user-named sections whose identifiers aren't actually significant and don't end up in the parsed structure is probably wasting a ton of people's time as they Google documentation for config section names that the consuming program doesn't actually understand because they don't really exist (they were just named at the author's whimsy).

It's not worth it. Use JSON, or possibly JSON5.

Take a look at TOML next time, very simple syntax and a lot of libraries coming around. I've been using it in every new project I start when I end up wanting configuration.

https://github.com/toml-lang/toml

If yaml ever gets too cranky, just use JSON in your yaml document.

Since yaml is a superset of json, any valid json is valid yaml as well. This allows you to combine the two in very convenient ways:

  ---
  test:
    obj: {"solution": ["in", "the", "list", {"everything: "is possible"}]}

> yaml is a superset of json, any valid json is valid yaml as well

This is wrong.

http://p3rl.org/JSON::XS#JSON-and-YAML

I can never remember the syntax for YAML, and it seems too complex and very fragile.

I rather just start with a real Python or JavaScript object literal in my source, and when it grows, move it to a new file, and run over it with a lenient JSON parser.

Reply on news.ycombinator.com