6 ms·

If you just want to get the configuration file part of your program working so you can focus on other things, JSON is a fairly quick and easy option. You could

If you just want to get the configuration file part of your program working so you can focus on other things, JSON is a fairly quick and easy option. You could make a more user-friendly format, but that might take longer.

seiferteric 9y ago
YAML is better for this.
- fomojola 9y ago
  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.
  - torrent-of-ions 9y ago
    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.
    - fragmede 9y ago
      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
    - fomojola 9y ago
      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).
  - jorvi 9y ago
    No significant whitespace you say? Take a peek at this: https://paste.ofcode.org/n9q3dnDcPDK5KLex54z6uw https://paste.ofcode.org/n9q3dnDcPDK5KLex54z6uw
    - rockostrich 9y ago
      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.
- fake-name 9y ago
  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.
  - exogen 9y ago
    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.
  - simcop2387 9y ago
    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 https://github.com/toml-lang/toml
  - gnur 9y ago
    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"}]}
    - 9y ago
- captainmuon 9y ago
  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.

seiferteric 9y ago

YAML is better for this.

fomojola 9y ago
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.
- torrent-of-ions 9y ago
  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.
  - fragmede 9y ago
    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
  - fomojola 9y ago
    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).
- jorvi 9y ago
  No significant whitespace you say? Take a peek at this: https://paste.ofcode.org/n9q3dnDcPDK5KLex54z6uw https://paste.ofcode.org/n9q3dnDcPDK5KLex54z6uw
  - rockostrich 9y ago
    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.
fake-name 9y ago
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.
- exogen 9y ago
  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.
- simcop2387 9y ago
  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 https://github.com/toml-lang/toml
- gnur 9y ago
  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"}]}
  - 9y ago
captainmuon 9y ago
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.