Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"No, JSON doesn't count. You know why." #2

Closed
getify opened this issue Feb 24, 2013 · 23 comments
Closed

"No, JSON doesn't count. You know why." #2

getify opened this issue Feb 24, 2013 · 23 comments

Comments

@getify
Copy link

getify commented Feb 24, 2013

Actually, no, I don't know why. Why? (not trolling, serious)

@mojombo
Copy link
Member

mojombo commented Feb 24, 2013

{ 'because': { '80': 'percent' }, {'of': 'JSON', 'is': 'brackets' } }

@mojombo mojombo closed this as completed Feb 24, 2013
@sintaxi
Copy link

sintaxi commented Feb 24, 2013

@mojombo your JSON is invalid (keys must be in double quotes). Perhaps you should brush up on the worlds most popular object notation before attempting to come up with an alternative.

@meeech
Copy link

meeech commented Feb 24, 2013

@getify also, JSON doesn't allow comments, which can be useful

@jm
Copy link

jm commented Feb 24, 2013

@danielribeiro It's all great fun until someone misses an indent. Then someone dies. :trollface:

@danielribeiro
Copy link

@jm I kinda like the idea of disrupting YAML, JSON and INI files, all at once. The fact that nobody even had mentioned XML is a huge win already.

@meeech
Copy link

meeech commented Feb 24, 2013

@danielribeiro re: xml - it's only been an hour, the night is young. 🍻

@kennethrapp
Copy link

I like brackets. Brackets are cool.

@ryancole
Copy link

but what about XML?

@sintaxi
Copy link

sintaxi commented Feb 24, 2013

@danielribeiro check this out. https://github.com/bevry/cson

@clarle
Copy link

clarle commented Feb 24, 2013

@meeech It's true that JSON doesn't have comments, but there are some ways around it, like piping the JSON configuration file through a minifier before directly using it. It's actually suggested to do this by Crockford himself.

@getify
Copy link
Author

getify commented Feb 24, 2013

@meech @clarle i happen to have written a simple PoC for pre-processing JSON to strip comments (and, in this case, whitespace too, since that's basically free): JSON.minify.

I've been advocating the usage of comments in JSON (when used as config files, not when used as a transmission data format) for a few years now. So the lack of comments is a non-issue as far as I'm concerned.

The "verbosity" of having too many { } is a different issue. I guess that's more a matter of taste, because I find it helpful to disambiguate nesting more than whitespace or just free-range section headers.

@unknwon
Copy link

unknwon commented May 16, 2013

@jm I love you comments, it's so lovely!

@ricardobeat
Copy link
Contributor

JSON is not necessarily human-readable. It doesn't allow comments, for frivolous reasons:

“people were using comments wrongly, so I removed them. Also, handling comments made the parser harder to implement, so I removed them. Also, comments didn’t exist in YAML and I wanted JSON to look like YAML, so I removed them.”

It also requires double quotes, for no apparent reason. Deep nesting sucks.

@jm just like missing a bracket, but way easier to spot :)

CSON was a great idea, but the implementation is a hack.

@88Alex
Copy link

88Alex commented May 16, 2013

"and" : { "json" : { "is" : "prone" , "to" : [ "syntax", "errors" ] } } }
Such as the one in here

@getify
Copy link
Author

getify commented May 17, 2013

hogwash. because xml and yaml and toml and every other format ever conceived are immune to syntax errors and json is a magnet for them. riiiight.

@BurntSushi
Copy link
Member

@getify Are you really trying to imply that all languages are equally susceptible to syntax errors? Talk about hogwash...

@getify
Copy link
Author

getify commented May 17, 2013

@BurntSushi I am not implying anything. I'm coming right out and saying bluntly and directly that JSON's susceptibility to syntax errors is no more of a disqualification for it as a format for config files (and such) than a variety of other formats that are used for that same task. That doesn't say they're equal, it's says the differences are not enough to matter in this discussion.

To suggest, in a strawman way as @88Alex did, that it's somehow more "prone" to errors than others, without any concrete comparison or support except a stupid joke of an example, is... well... hogwash.

I write lots of JSON in config files and I use a good editor that helps me find errors before I even save the file, and I don't make many mistakes writing JSON anyway, so it's not an issue for me. If you have trouble writing JSON, I bet you have trouble writing lots of other curly-brace things like, you know, every C-descendant language on the planet.

If you have trouble writing JSON, I feel bad for you son, I got 99 problems but JSON syntax aint one.

@BurntSushi
Copy link
Member

I am not implying anything. I'm coming right out and saying bluntly and directly that JSON's susceptibility to syntax errors is no more of a disqualification for it as a format for config files (and such) than a variety of other formats that are used for that same task.

If you were blunt, then you'd say: "I don't acknowledge the susceptibility of syntax errors as a valid reason to choose a configuration file format."

That's cool. But clearly other people here do. Feel bad for us all you want.

I write lots of JSON in config files and I use a good editor that helps me find errors before I even save the file, and I don't make many mistakes writing JSON anyway, so it's not an issue for me. If you have trouble writing JSON, I bet you have trouble writing lots of other curly-brace things like, you know, every C-descendant language on the planet.

Allow me to bow down to your superior skill at writing JSON.

@getify
Copy link
Author

getify commented May 17, 2013

If you were blunt, then you'd say: "I don't acknowledge the susceptibility of syntax errors as a valid reason to choose a configuration file format."

That's not what I'm saying. I guess I have to say it a third time. I am saying that even if JSON is a bit more prone to syntax errors, because it has more syntax than say, TOML, that extra susceptibility is not enough to abjectly disqualify JSON as a config file format.

You can prefer a simpler format (like TOML), fine. But this issue thread isn't about opinions of why TOML is better than JSON at configuration. That's a subjective discussion at best. It's about my objection to the statement that JSON is so much self-obviously inferior at this task as to not even warrant an explanation of the inferiority, with the smug "You know why." I genuinely wanted to know if there was actually anything objective or concrete underlying the subjective sarcasm.

To suggest/imply that JSON is so much more prone to errors than any other candidate format as to justify, just as this thread's original quote ("No, JSON doesn't count.") does, dismissiveness, and really not have anything except sarcasm to back that up... that's why I object(ed).

The confirmation from how this thread has largely gone thus far is that there really isn't any actual justification, just personal bias. And that's fine.

Allow me to bow down to your superior skill at writing JSON.

Thanks for putting me in my place. You clearly have the superior skills at everything else, especially sarcasm.

@ricardobeat
Copy link
Contributor

The differences were enough to warrant the creation of a totally new format. Judging by the project's uptake, it resonated with a lot of people.

Not long ago JSON overtook XML, but XML is a "fine" format too.

The confirmation from how this thread has largely gone thus far is that there really isn't any actual justification, just personal bias.

@getify I gave at least two objective reasons (readability, comments). Before you say readability is subjective, JSON can be minified, TOML can't, and there is a pretty concrete basis (number of control characters) to say that.

@BurntSushi
Copy link
Member

I genuinely wanted to know if there was actually anything objective or concrete underlying the subjective sarcasm.

The continued annoyances that people (not you) have with writing JSON. I can't imagine what other evidence there could be.

Thanks for putting me in my place.

My pleasure.

@Tanz0rz
Copy link

Tanz0rz commented Apr 24, 2015

@BurntSushi @getify

Pretty new to GitHub. You both made me laugh while I was reading this at work. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests