Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JSON with Commas and Comments

nigeltao.github.io

Post reply on HN
Print view View original

81–90 of 251 posts

Re: JSON with Commas and Comments

#81

Post by tshaddox »

Swizec wrote: post #74
skeeter2020 wrote: post #73

Could we solve dates first, then worry about comments and commas?

ISO-8601 not good enough for you? It’s a standard, human readable, has every datetime detail, every language that supports JSON can read it. What’s missing?

Be careful ever saying “every datetime detail”! An obvious one is that ISO 8601 can’t represent the location of the local time with enough information to know the current (or historical) daylight saving time rules for that location. You might not need that now, but you might if you’re building a calendar app!

ISO 8601 can represent a simple offset from UTC, but it can’t do a lot of the things that the IANA time zone database can do.

Re: JSON with Commas and Comments

#82

Post by ncallaway »

Swizec wrote: post #74
skeeter2020 wrote: post #73

Could we solve dates first, then worry about comments and commas?

ISO-8601 not good enough for you? It’s a standard, human readable, has every datetime detail, every language that supports JSON can read it. What’s missing?

I've never had a problem with dates by always serializing them as ISO-8601.

It absolutely has every benefit you cite.

It's the only ISO spec I know the name of without having to look it up.

Re: JSON with Commas and Comments

#83

Post by ncallaway »

tlb wrote: post #77
skeeter2020 wrote: post #73

Could we solve dates first, then worry about comments and commas?

Truly representing dates would make the semantics more complicated than JSON, Javascript, CSS, and C++20 combined. The practical approaches are to represent it as time since the Epoch (in floating point) or a string where both sides somehow agree what "03/04/05" means.

I'd recommend always representing dates or datetimes as a string in ISO-8601 format.

Re: JSON with Commas and Comments

#84

Post by ncallaway »

didibus wrote: post #43
hn_throwaway_99 wrote: post #31

Earlier quoted context omitted.

I can't believe that anyone who has ever wanted to comment a package.json file could think Crockford's argument is anything but nonsense. The problem is these files are both edited by humans, and by a plethora of tools. Without a standard comment format, it's been a nightmare trying to comment package.json file in a way that doesn't break something in the NPM/Node ecosystem.

Using JSON for configuration could be the mistake? That wasn't the original goal of JSON.

What if it's a goal of JWCC?

Re: JSON with Commas and Comments

#85

Post by yedpodtrzitko »

jugg1es wrote: post #66

Why can't these no-brainer features just be added to browsers without a new standard!!

You mean like when Google implements some Chrome-only features crippling other browsers, so people are indirectly forced to switch to their browser? We've been through the era of "this website works only in IE6 and better" already and I cant remember a single advantage it would bring.

Re: JSON with Commas and Comments

#86

Post by coldtea »

qyv wrote: post #75
coldtea wrote: post #58

Earlier quoted context omitted.

> That wasn't the original goal of JSON. That's neither here, nor there. The narrow vision many/most tools were created with is laughable compared to the actual creative uses people put them into. Heck, the internet wasn't created for collaborating, socializing, shopping, reading, listening to music, etc., anyway, it was created to have a war-proof network for army use, yet here we are...

Who is to say what to legitimate use and what is misuse of a creation if not the creator?

Obvioysly the world at large.

Would you consider your use of fire (e.g. for cooking) "illegitimate" if the creator of fire said so? ("No, must eat food raw! Fire is meant for heating only! Ugh!").

Re: JSON with Commas and Comments

#87

Post by hn_throwaway_99 »

tshaddox wrote: post #79
hn_throwaway_99 wrote: post #53

Earlier quoted context omitted.

My point is that I don't buy Crockford's argument, at all, against having comments in JSON. "I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability". So instead you have people coming up with a million different bad hacks to support comments in non standard ways (e.g. "fake comment" properties, duplicate keys, etc.) Coupled…

I’ve personally never encountered any combination of JSON-encoded data and JSON parser that didn’t work perfectly together. I don’t know whether the right trade-offs were made between interoperability and other features, but I’d say it’s very clear that if interoperability was a chief design goal, it was executed extremely well.

I don't understand why you keep making the same circular arguments. If the lowest-level standard for JSON-encoded data also included comments and trailing commas, than I have no doubt that every combination of JSON-encoded data and JSON parser would be able to parse that. Instead, it wasn't put in the lowest level spec, so instead what you have are lots of individual parsers with non-compatible custom flags. If Crockford's argument was "I got rid of comments because people were using them for preprocessor directives", then he just made the problem a million times worse because now there are a million different, incompatible "preprocessor directives" that are just implemented as basically command line args now if a user wants to have a very basic feature, which is comments.

Re: JSON with Commas and Comments

#88

Post by zeroimpl »

dmitryminkovsky wrote: post #65
zeroimpl wrote: post #10

Rather than keep making new variants of JSON, it'd be nice if somebody could convince some mainstream language maintainers to just update their built-in JSON parser to add optional features like skipping over comments and not caring about trailing commas. Most parsers support various flags already to configure things, so there could just be an ALLOW_COMMENTS flag and ALLOW_TRAILING_COMMAS flag. As a case in point, th…

JSON parsing is already a minefield. Please see [0], specifically this chart [1]. As mentioned in a sibling comment, I think a new mimetype makes a lot more sense sense than stirring this pot further. [0] http://seriot.ch/parsing_json.php [1] http://seriot.ch/json/pruned_results.png

It is a minefield, but we all walk it all the time.

A new mime type doesn’t really help because the parser doesn’t check the mime type, it assumes the programmer did that. I’m not against making a new mime type or specification, but there are already so many and making more doesn’t seem to help. Yes it would be nice if PHP and Python implement the logic for ignoring trailing commas the same way, but 99% of the time that isn’t all that important. Yes there will be cases where it matters and bugs are introduced, but since there already significant differences between JSON parsers I don’t see these kinds of things as making it much worse.

Re: JSON with Commas and Comments

#90

Post by BugsJustFindMe »

tshaddox wrote: post #79
hn_throwaway_99 wrote: post #53

Earlier quoted context omitted.

My point is that I don't buy Crockford's argument, at all, against having comments in JSON. "I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability". So instead you have people coming up with a million different bad hacks to support comments in non standard ways (e.g. "fake comment" properties, duplicate keys, etc.) Coupled…

I’ve personally never encountered any combination of JSON-encoded data and JSON parser that didn’t work perfectly together. I don’t know whether the right trade-offs were made between interoperability and other features, but I’d say it’s very clear that if interoperability was a chief design goal, it was executed extremely well.

> I’ve personally never encountered any combination of JSON-encoded data and JSON parser that didn’t work perfectly together.

As recently as 2017, the Google Translate API used to return completely invalid JSON with empty array indices instead of nulls ([,,,] instead of [null,null,null,null]). This broke several JSON parsers until they patched around Google's cavalier abuse of the language. Your experience of everything always working perfectly doesn't mean that everything always works perfectly.

Post reply on HN