5 ms·

Personally I've never found that to be an issue when using JSON as a data interchange format. The only place I'd like to have comments is in configuration file

Personally I've never found that to be an issue when using JSON as a data interchange format. The only place I'd like to have comments is in configuration files and in that case there are less verbose formats that do allow for comments.

viraptor 9y ago
I never really understood json for config files. It's not that readable. It's great for data exchange and relatively human-readable representation, but if you ask people to actually write and maintain it, why not yaml / toml / ...?
- vidarh 9y ago
  YAML suffers from significant whitespace, which makes me for one refuse to ever consider it. Personally I consider YAML less human writable than JSON for that reason. TOML is tolerable, but all my preferred languages already have JSON parsers I'm familiar with, but while they may have TOML parsers, I'd have to go looking for onne.
  - jghn 9y ago
    HOCON[1] is a pretty reasonable compromise, IMO. I've really only seen it used by Scala and Scala-y Java, which makes sense considering its lineage. [1] https://en.wikipedia.org/wiki/HOCON https://en.wikipedia.org/wiki/HOCON
- krapp 9y ago
  JSON is readable enough. The format is simple - no inline functions, no circular references, just maps or arrays of key-value pairs. This makes it well suited for describing what a config file should, which is an initial application state, without much needless abstraction. Config isn't meant to be code, and config files shouldn't be updated often, so a config file format doesn't need a great deal of expressiveness. Dealing with quoting keys and commas in JSON isn't more or less of a hassle than dealing with significant whitespace or whatever pecadillos those other formats have. Although personally I really like Lua tables for config because they have an even simpler structure than JSON and you can add comments. I have to resist the tempation to turn Lua config files into applications, though.
  - viraptor 9y ago
    It's also got issues though. Multiline text, undefined number ranges / interpretation for example.
- mschuster91 9y ago
  yaml has different "standards" depending which parser you ask and it is dead strict on whitespace (some parsers dont like tabs at all, and heaven forbid mixing spaces and tabs in one file). JSON doesnt care as long as it's valid, and there are parsers for every language and environment.
  - viraptor 9y ago
    There's only one official source for specification: http://www.yaml.org/spec/1.2/spec.html http://www.yaml.org/spec/1.2/spec.html If the parsers do something different, that's an implementation issue, which inevitably affects all formats. This affects json as well: http://seriot.ch/parsing_json.php http://seriot.ch/parsing_json.php
- Macha 9y ago
  Deserialisation is usually a one liner in your languages built in stdlib. Yaml/toml are not built in, though you may be able to try toml with your ini parser.
  - viraptor 9y ago
    For the rest, it's just an equivalent of "import yaml" before you use a one-liner as usual. Is it really a big problem?
lloeki 9y ago
> Personally I've never found that to be an issue when using JSON as a data interchange format. I had to diff on-wire JSON payloads to find a discrepancy, and boy was it a pain, whereas having those trailing commas would have reduced the diff to a quite direct and obvious pointer to the faulty change.
- dozzie 9y ago
  Convert to YAML and make unidiff from there?
- foobarchu 9y ago
  It doesn't solve your problem in the past, but if you run into this again in the future i've found it's really effective to stream your payloads through jq and have it the objects to compare by key first.

viraptor 9y ago

I never really understood json for config files. It's not that readable. It's great for data exchange and relatively human-readable representation, but if you ask people to actually write and maintain it, why not yaml / toml / ...?

vidarh 9y ago
YAML suffers from significant whitespace, which makes me for one refuse to ever consider it. Personally I consider YAML less human writable than JSON for that reason. TOML is tolerable, but all my preferred languages already have JSON parsers I'm familiar with, but while they may have TOML parsers, I'd have to go looking for onne.
- jghn 9y ago
  HOCON[1] is a pretty reasonable compromise, IMO. I've really only seen it used by Scala and Scala-y Java, which makes sense considering its lineage. [1] https://en.wikipedia.org/wiki/HOCON https://en.wikipedia.org/wiki/HOCON
krapp 9y ago
JSON is readable enough. The format is simple - no inline functions, no circular references, just maps or arrays of key-value pairs. This makes it well suited for describing what a config file should, which is an initial application state, without much needless abstraction. Config isn't meant to be code, and config files shouldn't be updated often, so a config file format doesn't need a great deal of expressiveness. Dealing with quoting keys and commas in JSON isn't more or less of a hassle than dealing with significant whitespace or whatever pecadillos those other formats have. Although personally I really like Lua tables for config because they have an even simpler structure than JSON and you can add comments. I have to resist the tempation to turn Lua config files into applications, though.
- viraptor 9y ago
  It's also got issues though. Multiline text, undefined number ranges / interpretation for example.
mschuster91 9y ago
yaml has different "standards" depending which parser you ask and it is dead strict on whitespace (some parsers dont like tabs at all, and heaven forbid mixing spaces and tabs in one file). JSON doesnt care as long as it's valid, and there are parsers for every language and environment.
- viraptor 9y ago
  There's only one official source for specification: http://www.yaml.org/spec/1.2/spec.html http://www.yaml.org/spec/1.2/spec.html If the parsers do something different, that's an implementation issue, which inevitably affects all formats. This affects json as well: http://seriot.ch/parsing_json.php http://seriot.ch/parsing_json.php
Macha 9y ago
Deserialisation is usually a one liner in your languages built in stdlib. Yaml/toml are not built in, though you may be able to try toml with your ini parser.
- viraptor 9y ago
  For the rest, it's just an equivalent of "import yaml" before you use a one-liner as usual. Is it really a big problem?

lloeki 9y ago

> Personally I've never found that to be an issue when using JSON as a data interchange format. I had to diff on-wire JSON payloads to find a discrepancy, and boy was it a pain, whereas having those trailing commas would have reduced the diff to a quite direct and obvious pointer to the faulty change.

dozzie 9y ago
Convert to YAML and make unidiff from there?
foobarchu 9y ago
It doesn't solve your problem in the past, but if you run into this again in the future i've found it's really effective to stream your payloads through jq and have it the objects to compare by key first.