7 ms·

Apologies for the somewhat off-topic remark, but ... Can we please stop creating new JSON-based config files? Sane config file formats must support comments.

kkirsche 11y ago
100% agreed. This is the reason I personally find YAML to be a great config alternative to JSON due to their ease of converting between the two
- brandonbloom 11y ago
  YAML isn't a particularly good config format either, since it has a lot of unnecessary complexity. For example, bare words are strings, but some bare words, such as "true" are booleans. Which wouldn't be so bad, but did you know that "yes" and "no" are also booleans? I've gotten YAML files from an i18n-system that screwed this up in a pretty bad way.
- jonaf 11y ago
  In fact, YAML is a superset of JSON, and any valid JSON is also valid YAML. This becomes more obvious when you realize you can put any JSON objects inside of your YAML document and any YAML parser will correctly deserialize it.
Sanddancer 11y ago
I wouldn't apologize for that, you're addressing the elephant in the room here. JSON has turned into the new XML. There seems to be a pervasive undercurrent that if it looks website-ish, it's got to be good. So it seems to be used quite a bit in lieu of looking carefully at the problem and figuring out the best structured format. Configuration files tend to have a lot of ambiguity in them, going to a format that makes it all that much harder to pull out the why part of settings does nothing to improve on that.
- geofft 11y ago
  > There seems to be a pervasive undercurrent that if it looks website-ish, it's got to be good. I don't get that from the article. There's a stated reason, that it's a stricter format with much less risk of type confusion, which sounds plausible enough to me. There's also the benefit that tool support is good. Why does the web need to be relevant at all?
  - lsaferite 11y ago
    Doesn't YAML fill the same slot, allow comments, and allow much saner human interaction? And as a bonus it's 100% (?) convertible to JSON (minus comments of course)
    - geofft 11y ago
      You'd have to add a validator to disallow some of the weirder YAML syntaxes. And once you have such a validator, you have neither JSON (it won't parse) nor YAML (it's dangerous to parse the file as YAML without running it through the validator first).
- benley 11y ago
  Honestly, I don't think JSON config files are a big problem. What's shitty is when humans are expected to manually create and edit plain JSON, but what's stopping us from using whatever tools we want to generate those JSON configs? There are some very nice tools out there for this; I have taken to using jsonnet (http://jsonnet.org/ http://jsonnet.org/), which is excellent as a configuration language. It's pretty comparable to Hashicorp's HCL, but it's a standalone thing. Summary: Write your config files in a language of your choice. Render them to JSON for your apps to consume. Be thankful that every app doesn't have its own special snowflake config format like they used to.
  - seanp2k2 11y ago
    Ooh, they still do, especially things by Elastic.
pm 11y ago
Any suggestions for a format that is sane?
- mintplant 11y ago
  TOML. https://github.com/toml-lang/toml https://github.com/toml-lang/toml
  - nikolay 11y ago
    [[ something ]]? No, thank you! Jsonnet [0], yes, please! [0]: http://jsonnet.org/ http://jsonnet.org/
    - placeybordeaux 11y ago
      Why?
      - nikolay 11y ago
        It's just weird syntax in my view.
  - brandonbloom 11y ago
    I (original commenter) second TOML. It is very simple, is instantly familiar to anyone who has used ini files or many Unix-style config files, and has many good implementations available. The [[array]] notation mentioned below is a tad weird, but I've never had an occasion to use it.
- ddispaltro 11y ago
  My personal favorite is HOCON from Typesafe, https://github.com/typesafehub/config#examples-of-hocon https://github.com/typesafehub/config#examples-of-hocon
- cookrn 11y ago
  Hashicorp has created HCL https://github.com/hashicorp/hcl https://github.com/hashicorp/hcl
otterley 11y ago
At long as an app isn't strictly validating the JSON, you should be able to add keys like { "comment": "this does xxx" } to a JSON configuration object.
- e12e 11y ago
  There's that, or: "Comments in JSON I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I know that the lack of comments makes some people sad, but it shouldn't. Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser." https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaGSr https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaG...
  - seanp2k2 11y ago
    The idea that one would install node + npm + some linter + linter configs + some method of automatically running the linter against the config before sending it to the thing being configured seems pretty insane and unnecessary to me. At the end of the day, it can suck, but being able to look at a config on a running system with inline comments makes debugging infra problems much easier. What the heck was wrong with # comments and the types of configs Apache et al. Have been using for decades?
    - otterley 11y ago
      Nothing, but then you get to write your own parser for whatever bespoke configuration DSL you want to implement. Some people would rather focus on other aspects of functionality.
  - brandonbloom 11y ago
    Rather than remove comments, address the primary use case: https://github.com/edn-format/edn#tagged-elements https://github.com/edn-format/edn#tagged-elements
pjmlp 11y ago
I just keep using XML, when the decision falls on my side. - It supports comments; - A very flexible format; - I don't care it is verbose, it should be managed by tools anyway - Can be automatically validated; - Plenty of tools to choose from

kkirsche 11y ago

100% agreed. This is the reason I personally find YAML to be a great config alternative to JSON due to their ease of converting between the two

brandonbloom 11y ago
YAML isn't a particularly good config format either, since it has a lot of unnecessary complexity. For example, bare words are strings, but some bare words, such as "true" are booleans. Which wouldn't be so bad, but did you know that "yes" and "no" are also booleans? I've gotten YAML files from an i18n-system that screwed this up in a pretty bad way.
jonaf 11y ago
In fact, YAML is a superset of JSON, and any valid JSON is also valid YAML. This becomes more obvious when you realize you can put any JSON objects inside of your YAML document and any YAML parser will correctly deserialize it.

Sanddancer 11y ago

I wouldn't apologize for that, you're addressing the elephant in the room here. JSON has turned into the new XML. There seems to be a pervasive undercurrent that if it looks website-ish, it's got to be good. So it seems to be used quite a bit in lieu of looking carefully at the problem and figuring out the best structured format. Configuration files tend to have a lot of ambiguity in them, going to a format that makes it all that much harder to pull out the why part of settings does nothing to improve on that.

geofft 11y ago
> There seems to be a pervasive undercurrent that if it looks website-ish, it's got to be good. I don't get that from the article. There's a stated reason, that it's a stricter format with much less risk of type confusion, which sounds plausible enough to me. There's also the benefit that tool support is good. Why does the web need to be relevant at all?
- lsaferite 11y ago
  Doesn't YAML fill the same slot, allow comments, and allow much saner human interaction? And as a bonus it's 100% (?) convertible to JSON (minus comments of course)
  - geofft 11y ago
    You'd have to add a validator to disallow some of the weirder YAML syntaxes. And once you have such a validator, you have neither JSON (it won't parse) nor YAML (it's dangerous to parse the file as YAML without running it through the validator first).
benley 11y ago
Honestly, I don't think JSON config files are a big problem. What's shitty is when humans are expected to manually create and edit plain JSON, but what's stopping us from using whatever tools we want to generate those JSON configs? There are some very nice tools out there for this; I have taken to using jsonnet (http://jsonnet.org/ http://jsonnet.org/), which is excellent as a configuration language. It's pretty comparable to Hashicorp's HCL, but it's a standalone thing. Summary: Write your config files in a language of your choice. Render them to JSON for your apps to consume. Be thankful that every app doesn't have its own special snowflake config format like they used to.
- seanp2k2 11y ago
  Ooh, they still do, especially things by Elastic.

pm 11y ago

Any suggestions for a format that is sane?

mintplant 11y ago
TOML. https://github.com/toml-lang/toml https://github.com/toml-lang/toml
- nikolay 11y ago
  [[ something ]]? No, thank you! Jsonnet [0], yes, please! [0]: http://jsonnet.org/ http://jsonnet.org/
  - placeybordeaux 11y ago
    Why?
    - nikolay 11y ago
      It's just weird syntax in my view.
- brandonbloom 11y ago
  I (original commenter) second TOML. It is very simple, is instantly familiar to anyone who has used ini files or many Unix-style config files, and has many good implementations available. The [[array]] notation mentioned below is a tad weird, but I've never had an occasion to use it.
ddispaltro 11y ago
My personal favorite is HOCON from Typesafe, https://github.com/typesafehub/config#examples-of-hocon https://github.com/typesafehub/config#examples-of-hocon
cookrn 11y ago
Hashicorp has created HCL https://github.com/hashicorp/hcl https://github.com/hashicorp/hcl

otterley 11y ago

At long as an app isn't strictly validating the JSON, you should be able to add keys like { "comment": "this does xxx" } to a JSON configuration object.

e12e 11y ago
There's that, or: "Comments in JSON I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I know that the lack of comments makes some people sad, but it shouldn't. Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser." https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaGSr https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaG...
- seanp2k2 11y ago
  The idea that one would install node + npm + some linter + linter configs + some method of automatically running the linter against the config before sending it to the thing being configured seems pretty insane and unnecessary to me. At the end of the day, it can suck, but being able to look at a config on a running system with inline comments makes debugging infra problems much easier. What the heck was wrong with # comments and the types of configs Apache et al. Have been using for decades?
  - otterley 11y ago
    Nothing, but then you get to write your own parser for whatever bespoke configuration DSL you want to implement. Some people would rather focus on other aspects of functionality.
- brandonbloom 11y ago
  Rather than remove comments, address the primary use case: https://github.com/edn-format/edn#tagged-elements https://github.com/edn-format/edn#tagged-elements

pjmlp 11y ago

I just keep using XML, when the decision falls on my side. - It supports comments; - A very flexible format; - I don't care it is verbose, it should be managed by tools anyway - Can be automatically validated; - Plenty of tools to choose from