I love this comment. JSON is by far the format that cares the least about being human-readable or -writable, but you’re seriously proposing writing it rather than YAML. And I kind of don’t even really disagree. But a big problem with that strategy is that you won’t find documentation for how to write the configuration in JSON.
I disagree that json is not human writable. JSON is perfectly writable since it has explicit visible separations between elements.
It might look ugly but it’s perfectly readable and writeable.
Granted, I always read json after parsing it with an auto formatter. Maybe that’s why people say that json is difficult to read? It’s true that unformatted json (minified) is way worse than yaml but no one in their right mind would not format the json, specially when it’s natively supported by most code editors.
BTW, about documentation, post formatting json looks very much like a yaml, all yaml docs can be converted to json instructions if you think a little bit.
Oh, that is actually the part I do agree with. I don’t think everyone will, but I do actually think JSON is easier to read and write (correctly) than YAML. I specifically wrote that JSON cares the least about that, because it was designed to just serialize JavaScript objects into strings and back. As far as its original purpose is concerned, no one would ever need to hand-edit JSON. Which is also why it doesn’t support comments (which is still somewhat of a dealbreaker for a configuration language, although I guess for your proposed workaround, one could potentially use a JSON flavor which supports comments; potentially, you can even write your JSON in the YAML file with comments directly and then not convert it, since YAML is a superset of JSON).
As for documentation, yeah, it is possible to convert, but it makes it more annoying, particularly also if you then can’t easily re-use configs in another project. And if you’re working in a team, having to explain to all your team members, how they can convert the official documentation, is also not really acceptable…
Because … well … wait, not a bad idea. Although, this would get rid of comments. Which in my case, I didn’t have too many, so I could have manually added them back.
Yeah, I’ve definitely grown to like TOML, especially after spending hours trying to edit a giant (nested) YAML file…
I didn’t realize the indentation in TOML was purely aesthetic.
This
[servers] [servers.alpha] ip = "10.0.0.1" dc = "eqdc10" [servers.beta] ip = "10.0.0.2" dc = "eqdc10"equals this
[servers] [servers.alpha] ip = "10.0.0.1" dc = "eqdc10" [servers.beta] ip = "10.0.0.2" dc = "eqdc10"which equals this
{ "servers": { "alpha": { "ip": "10.0.0.1", "dc": "eqdc10" }, "beta": { "ip": "10.0.0.2", "dc": "eqdc10" } } }Once the file is big enough wouldn’t it be better to convert it to json before editing, then converting it back?
Let the computer deal with indents and all that stuff.
I love this comment. JSON is by far the format that cares the least about being human-readable or -writable, but you’re seriously proposing writing it rather than YAML. And I kind of don’t even really disagree. But a big problem with that strategy is that you won’t find documentation for how to write the configuration in JSON.
I disagree that json is not human writable. JSON is perfectly writable since it has explicit visible separations between elements.
It might look ugly but it’s perfectly readable and writeable.
Granted, I always read json after parsing it with an auto formatter. Maybe that’s why people say that json is difficult to read? It’s true that unformatted json (minified) is way worse than yaml but no one in their right mind would not format the json, specially when it’s natively supported by most code editors.
BTW, about documentation, post formatting json looks very much like a yaml, all yaml docs can be converted to json instructions if you think a little bit.
Oh, that is actually the part I do agree with. I don’t think everyone will, but I do actually think JSON is easier to read and write (correctly) than YAML. I specifically wrote that JSON cares the least about that, because it was designed to just serialize JavaScript objects into strings and back. As far as its original purpose is concerned, no one would ever need to hand-edit JSON. Which is also why it doesn’t support comments (which is still somewhat of a dealbreaker for a configuration language, although I guess for your proposed workaround, one could potentially use a JSON flavor which supports comments; potentially, you can even write your JSON in the YAML file with comments directly and then not convert it, since YAML is a superset of JSON).
As for documentation, yeah, it is possible to convert, but it makes it more annoying, particularly also if you then can’t easily re-use configs in another project. And if you’re working in a team, having to explain to all your team members, how they can convert the official documentation, is also not really acceptable…
Because … well … wait, not a bad idea. Although, this would get rid of comments. Which in my case, I didn’t have too many, so I could have manually added them back.