Hacker News Reader

Comment by norcalli | Hacker News Reader

I've never understood this. JSON is really not that difficult to work with manually. I tend to write my config files as JSON for utilities I write. What is it with peoples' innate aversion to braces?

View on HN

I don't aversion to braces. Rather, my issues with JSON is that it doesn't have comments and that you cannot use a optional trailing comma.

Having spent a nontrivial amount of my life hand editing large JSON files now, I have to agree here. Lack of comments and trailing commas are a real QOL issue.

And the required double quotes around strings. YAML’s string handling is a lot easier to deal with.

It’s also a lot less obvious. What’s so difficult about wrapping a string in double quotes?

It gets annoying when you have to do what seems unnecessary.

It's not really unnecessary when someone can write an entire article on how unfathomable the output is without them.

It’s easier until you hit one of the cases where a particular value is interpreted as a different type, possibly in a very confusing context. I’ve seen that bite enough people that I end up quoting strings to avoid confusion.

It’s also extremely hard to learn as a beginner.

“Hey, I deleted a character in a string and now I am getting this weird schema validation exception”.

Or “Why did it break when I changed the version from 3.7 to 3.7.1?”

I think it is good to require quotation marks for strings, at least for values (although I could live with it if quotation marks for strings are allowed even if not required, since then, if you do not like the feature of not having quotation marks for strings, you can just not use that feature).

Maybe it would be sense if quotation marks were not required for keys with only a restricted character set which are not an empty string, though.

No quotes around keys would be sufficient, honestly. I use YAML a lot for API documentation, and there are still some cases where wrapping your values in quotes is necessary. But requiring it for keys becomes very annoying.

https://json5.org/

JSON5 looks like good, actually. It has all of the added features that it should have.

They don't mention mismatched surrogates and otherwise invalid Unicode characters, but they should perhaps be implementation-dependent, like duplicate keys are. (It can either allow them or report an error.) There is also the possibility that some implementations may wish to disallow "\x00" or "\u0000" too, I think.

The thing I disagree is the part about white space. U+FEFF should be allowed only at the beginning of the document (optionally), and other than that only ASCII white space should be allowed. Unquoted keys also should be limited to ASCII characters.

Other than that, I think it is good.

Also no multiline strings. Using \n or string arrays is painful.

I don't get why TOML is so underrated, it's barely mentioned in the HN discussion

Thanks for mentioning it; I hadn't encountered it yet and it seems like a very sane config file format. There's several mentions in this discussion actually, nearly all positive.

JSON is serviceable as an intermediate format, machine-generated and machine-consumed.

It is outright bad as a human-operated format. It explicitly lacks comments, it does not allow trailing commas, it lacks namespaces, to name a few pain points.

YAML is much more human-friendly, with all its problems.

I often hear the “comments aren’t supported” argument against JSON, but as a daily consumer, creator, and maintainer of JSON, I honestly can’t recall ever _really_ needing comments in JSON. It tends to be somewhat self documenting in my experience.

A config file without comments can mean serious annoyance.

If JSON was developed more recently on places like GitHub, it would never have ended up like that with that many deficiencies.

When maintaining a JSON file, did you ever happen to wonder why a particular value is what it is?

This is where comments belong.

If it's that important and complex, have an accompanying README that lists line numbers and comments.

Lesson to learn: Nobody reads the docs.

This is such a dumb aphorism. I read and create docs every single day.

If the comments are so critical that it is a problem, then an accompanying file with those comments would be used. Otherwise, it's just a bunch of crocodile tears.

Good idea! And then put a comment into the configuration file that refers to where the documentation is.. ah, f__k!

The lack of comments is the real problem. When you need to explain why a particular parameter in the config file is set a certain way JSON becomes a real problem.

Comments, comments, comments.

Seriously, our batch jobs for better or worse have configs with a bunch of parameters that are passed around as json, and while most variable names are intuitive and there is documentation on the wiki, and most often the config can be autogenerated by other tools it would still be better if when I manually open it in the config itself I would easily see the difference between n_run_threads vs n_reg_threads, etc...

json's lack of int types is what ruins it for me

Reply on news.ycombinator.com