Hacker News Reader

Comment by SiVal | Hacker News Reader

I'd rather have trailing commas, so every line can have the same format. Other people choose JSON for their config file format, and I don't have a say in it. I just have to do extra editing each time I reorder the lines or add a new one, because too bad. And I have to manually edit JSON when I'm writing code to handle other people's JSON APIs to test my code.

I'll probably never not have to manually edit JSON, so JSON's insistence that using the same format for your final line as for all the others won't ever be allowed will remain a never ending, unnecessary nuisance in the spirit of JavaScript itself: the "too bad, too late now" school of design. Except that in this case, even JavaScript corrected that particular nuisance and allows trailing commas.

View on HN

All because IE6 wasn't supporting trailing commas at the time when JSON was written. Shortly after that we discovered that it was a bad idea to eval() JSON so the whole reason for browser compatibility became moot.

But who knows, maybe that is what was needed at the time to make JSON popular.

If you want a JSON-ish config format, I'd recommend to check out HOCON [1], basically a superset of JSON that fixes all he things that make it annoying for config files.

[1] https://github.com/lightbend/config

If we're proposing supersets of json, why wouldn't one just use yaml?

If the config is in the form of:

    {
        "file": "/etc/foo",
        "daemon": true
    }

Couldn't you add comments like so, all within the existing spec?

    {
        "file": "/etc/foo",

        "_daemon_comment": "default is false",
        "daemon": true
    }

The problem is that's not really a comment, it's a string which needs to be evaluated as data, wasting resources while never being used. In any sane language, comments are simply ignored by the parser or compiler.

Because Douglas Crockford didn't want people abusing comments in JSON by turning them into parsing directives, JSON doesn't allow using comments at all, even correctly, so everyone is left abusing JSON itself with workarounds that are objectively worse than just having comments.

if you're using json as a config file you can choose a json parser that supports comments. there are a number of them

At that point you're not writing JSON though. Once you start bolting on non-standard bells and whistles, why not recognize that JSON was never meant to be used for config files, and switch to something that was, like TOML [0]?

0: https://npf.io/2014/08/intro-to-toml/

Additionally, working against a json schema with additional properties false would cause a validation failure.

Reply on news.ycombinator.com