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

Comments

Projects
None yet
@getify

getify commented Feb 24, 2013

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

@mojombo

This comment has been minimized.

Show comment
Hide comment
@mojombo

mojombo Feb 24, 2013

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

mojombo commented Feb 24, 2013

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

@mojombo mojombo closed this Feb 24, 2013

@sintaxi

This comment has been minimized.

Show comment
Hide comment
@sintaxi

sintaxi 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.

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

This comment has been minimized.

Show comment
Hide comment
@meeech

meeech Feb 24, 2013

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

meeech commented Feb 24, 2013

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

@jm

This comment has been minimized.

Show comment
Hide comment
@jm

jm Feb 24, 2013

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

jm commented Feb 24, 2013

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

@danielribeiro

This comment has been minimized.

Show comment
Hide comment
@danielribeiro

danielribeiro Feb 24, 2013

@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.

danielribeiro commented Feb 24, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@meeech

meeech Feb 24, 2013

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

meeech commented Feb 24, 2013

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

@kennethrapp

This comment has been minimized.

Show comment
Hide comment
@kennethrapp

kennethrapp Feb 24, 2013

I like brackets. Brackets are cool.

kennethrapp commented Feb 24, 2013

I like brackets. Brackets are cool.

@ryancole

This comment has been minimized.

Show comment
Hide comment
@ryancole

ryancole Feb 24, 2013

but what about XML?

ryancole commented Feb 24, 2013

but what about XML?

@sintaxi

This comment has been minimized.

Show comment
Hide comment
@sintaxi

sintaxi commented Feb 24, 2013

@clarle

This comment has been minimized.

Show comment
Hide comment
@clarle

clarle 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.

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

This comment has been minimized.

Show comment
Hide comment
@getify

getify 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.

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

This comment has been minimized.

Show comment
Hide comment
@Unknwon

Unknwon May 16, 2013

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

Unknwon commented May 16, 2013

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

@ricardobeat

This comment has been minimized.

Show comment
Hide comment
@ricardobeat

ricardobeat May 16, 2013

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.

Contributor

ricardobeat commented May 16, 2013

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

This comment has been minimized.

Show comment
Hide comment
@88Alex

88Alex May 16, 2013

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

88Alex commented May 16, 2013

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

@getify

This comment has been minimized.

Show comment
Hide comment
@getify

getify 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.

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

This comment has been minimized.

Show comment
Hide comment
@BurntSushi

BurntSushi May 17, 2013

Member

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

Member

BurntSushi commented May 17, 2013

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

@getify

This comment has been minimized.

Show comment
Hide comment
@getify

getify 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.

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

This comment has been minimized.

Show comment
Hide comment
@BurntSushi

BurntSushi May 17, 2013

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.

Member

BurntSushi commented May 17, 2013

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

This comment has been minimized.

Show comment
Hide comment
@getify

getify 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.

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

This comment has been minimized.

Show comment
Hide comment
@ricardobeat

ricardobeat May 17, 2013

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.

Contributor

ricardobeat commented May 17, 2013

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

This comment has been minimized.

Show comment
Hide comment
@BurntSushi

BurntSushi May 17, 2013

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.

Member

BurntSushi commented May 17, 2013

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.

@TannerMoore

This comment has been minimized.

Show comment
Hide comment
@TannerMoore

TannerMoore Apr 24, 2015

@BurntSushi @getify

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

TannerMoore 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