4 ms·

To this day I am baffled why choose YAML? Personally, I think its more error prone, less flexible, and harder to read than JSON. Not to say JSON is a perfect fo

To this day I am baffled why choose YAML? Personally, I think its more error prone, less flexible, and harder to read than JSON. Not to say JSON is a perfect format, but it sure feels better than YAML.

charrondev 7y ago
Reason number 1: aliases and anchors. Reason number 2: allowing comments. JSON is a terrible config format, and an ok data interchange format.
- wpietri 7y ago
  Agreed. It amazes me that we got out of the XML-for-everything era with a lot of people thinking the problem was XML, and not the for-everything part. JSON-for-everything is just as maddening to me.
probably_wrong 7y ago
Comments was the reason for me to move from JSON to YAML in config files. I remember perfectly fine what every option does, but adding comments to each option is a must when it comes to sharing my code with anyone else.
- FlorianRappl 7y ago
  If its a config file I'm not sure why you'll need comments. Comments / documentation should be in the system you'll do the config for. If your set options are that quirky / need documentation; why not explain them in a README? But maybe I misunderstood. Can you give an example of a comment that makes sense / is required in a configuration JSON?
  - probably_wrong 7y ago
    > If your set options are that quirky / need documentation; why not explain them in a README? Mostly because I don't know whether the person customizing my code will read the README, but they'll definitely see the comments I wrote right before the configuration option itself. With comments and some extra whitespace, they can go through the file line by line, read what a specific option does, configure it properly, and move on to the next one. No back and forth to the README required.
orthoxerox 7y ago
JSON's finicky about commas. Quotation marks everywhere are a visual noise. Comments are accepted by many parsers, but not by all of them. Something like http://www.relaxedjson.org/ http://www.relaxedjson.org/ is a JSON we need. An implicit root object would make it almost perfect for writing configuration.

charrondev 7y ago

Reason number 1: aliases and anchors. Reason number 2: allowing comments. JSON is a terrible config format, and an ok data interchange format.

wpietri 7y ago
Agreed. It amazes me that we got out of the XML-for-everything era with a lot of people thinking the problem was XML, and not the for-everything part. JSON-for-everything is just as maddening to me.

probably_wrong 7y ago

Comments was the reason for me to move from JSON to YAML in config files. I remember perfectly fine what every option does, but adding comments to each option is a must when it comes to sharing my code with anyone else.

FlorianRappl 7y ago
If its a config file I'm not sure why you'll need comments. Comments / documentation should be in the system you'll do the config for. If your set options are that quirky / need documentation; why not explain them in a README? But maybe I misunderstood. Can you give an example of a comment that makes sense / is required in a configuration JSON?
- probably_wrong 7y ago
  > If your set options are that quirky / need documentation; why not explain them in a README? Mostly because I don't know whether the person customizing my code will read the README, but they'll definitely see the comments I wrote right before the configuration option itself. With comments and some extra whitespace, they can go through the file line by line, read what a specific option does, configure it properly, and move on to the next one. No back and forth to the README required.

orthoxerox 7y ago

JSON's finicky about commas. Quotation marks everywhere are a visual noise. Comments are accepted by many parsers, but not by all of them. Something like http://www.relaxedjson.org/ http://www.relaxedjson.org/ is a JSON we need. An implicit root object would make it almost perfect for writing configuration.