8 ms·

Slightly off-topic: Why is JSON so popular for this sort of thing? I think it's fine for programs communicating with each other, but I really don't understand w

Slightly off-topic: Why is JSON so popular for this sort of thing? I think it's fine for programs communicating with each other, but I really don't understand why anyone would want to have to match brackets when writing a configuration file

pjscott 9y ago
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.
logicallee 9y ago
because you're allowed and able to use tools. then the popularity of json is an advantage, as you could just use whatever tool you wanted to edit it, and its popularity would mean you have tons of choices. for example I just googled "lightweight online json editor mobile no registration" and was very pleased. the more popular json gets, the objectively better choice it becomes. you can edit it in a browser, as I just showed you, then copy the result over. it's great!
eat_veggies 9y ago
I like using JSON because - There are lots of great libraries for nearly every language to parse it, or they're built in - It's got the benefits of XML (tags are right next to the data, unlike CSV) while being way less typing - It's easy to scan since I'm already used to seeing [] and {} to represent common data structures - I can pretty print it or remove whitespace - It's popular, meaning there are lots of tools to work with it, but it's simple enough that a text editor will do - Most text editors will match brackets and indentation for me, so it's not a huge issue
- MichaelGG 9y ago
  If it just had comments, trailing commas, and didn't require quoting names, I could forgive the brace matching. Really shortsighted.
  - mercer 9y ago
    I don't know about the other stuff, but I sort of see why comments were not supported: https://news.ycombinator.com/item?id=3912149 https://news.ycombinator.com/item?id=3912149 Personally I do miss them tremendously though.
  - captainmuon 9y ago
    Some implementations allow comments. There is a project called JSON5 that also allows trailing commas, and maybe omitting quotes for keys. I have some (private) libraries in C++, Python, and Nim that support those features, too. Basically it understands JavaScript object literals. If I find some time, I'll package them up and publish them. One thing I'd really like to change is to make the parser round-trippable, so it remembers all the whitespace and comments, and if you use these pseudo-json as config files, you can make programmatic changes without loosing anything.
torrent-of-ions 9y ago
Probably the same reason you have people using XML for supposedly human read/writeable config files: it's hip.

pjscott 9y ago

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.

logicallee 9y ago

because you're allowed and able to use tools. then the popularity of json is an advantage, as you could just use whatever tool you wanted to edit it, and its popularity would mean you have tons of choices. for example I just googled "lightweight online json editor mobile no registration" and was very pleased. the more popular json gets, the objectively better choice it becomes. you can edit it in a browser, as I just showed you, then copy the result over. it's great!

eat_veggies 9y ago

I like using JSON because - There are lots of great libraries for nearly every language to parse it, or they're built in - It's got the benefits of XML (tags are right next to the data, unlike CSV) while being way less typing - It's easy to scan since I'm already used to seeing [] and {} to represent common data structures - I can pretty print it or remove whitespace - It's popular, meaning there are lots of tools to work with it, but it's simple enough that a text editor will do - Most text editors will match brackets and indentation for me, so it's not a huge issue

MichaelGG 9y ago
If it just had comments, trailing commas, and didn't require quoting names, I could forgive the brace matching. Really shortsighted.
- mercer 9y ago
  I don't know about the other stuff, but I sort of see why comments were not supported: https://news.ycombinator.com/item?id=3912149 https://news.ycombinator.com/item?id=3912149 Personally I do miss them tremendously though.
- captainmuon 9y ago
  Some implementations allow comments. There is a project called JSON5 that also allows trailing commas, and maybe omitting quotes for keys. I have some (private) libraries in C++, Python, and Nim that support those features, too. Basically it understands JavaScript object literals. If I find some time, I'll package them up and publish them. One thing I'd really like to change is to make the parser round-trippable, so it remembers all the whitespace and comments, and if you use these pseudo-json as config files, you can make programmatic changes without loosing anything.

torrent-of-ions 9y ago

Probably the same reason you have people using XML for supposedly human read/writeable config files: it's hip.