On: Hjson, the Human JSON

[JamilD]

Rigidity and consistency are not always bad things. They can help prevent bugs, security vulnerabilities, and they drastically reduce complexity of implementation.

JSON might often be too rigid, but I think it's important to note that "easier" (in that you don't need to learn the syntax) isn't always better.

[IvanK_net → JamilD]

This "easier" format is actually more "complex". JSON can be described with just a couple of simple rules (http://json.org/ ), while this format adds many new rules (e.g. for doing same things in multiple ways). The more rules you have, the more things you have to remember, the harder it is to find the reason of the problem.

BTW. it is very simple to do comments in JSON :) You can just add "comment1" : "This is my comment", to any object, it will be ignored by software that processes your file.

[mort96 → IvanK_net]

I kind of like doing comments like this:

    "#": " my comment"

[ZenPsycho → mort96]

the problem with that one is that some parsers have a meltdown if they encounter duplicate keys. sigh

[abraae → mort96]

Ha ha, I do exactly the same thing. Lack of comments is really the only beef I have with Json (well, no multi line text too I suppose).

A new spec that just addressed those alone would be great.

[kstenerud → JamilD]

Yes. There are two distinct use cases here: configuration files, and interchange formats.

For an interchange format, JSON does the job very well. Small, simple, human readable, easy to implement.

For a configuration format, JSON leaves a lot to be desired. It's almost there, but has enough warts to be annoying.

You're not going to get a one-size-fits-all format.

[collyw → JamilD]

This sounds more like Python dictionaries. I don't see more bugs when I am using those over JSON, and I find them a lot easier to work with.