51–60 of 251 posts
Earlier quoted context omitted.
Why not?
JSON is extremely closely linked with JavaScript. Trying to move it in a different direction, in my opinion, would require a lot of effort, without much benefit, and is unlikely to succeed.
People are more interested in JSON derivatives like JSON5 or Ion than more complex languages like Dhall in my experience.
Computer-generated data never needs to include trailing commas or comments.
Really the principal use case here is JSON as human-edited configuration files. In which case I suppose it's nice to have a name like "JWCC", but really it's just two flags for JSON decoding libraries to add (or a single nice combined flag).
So that really would be great IMHO, if you could just call json_decode($json, JSON_ALLOW_JWCC). I don't think we need a new MIME type or anything. But a file extension of ".jwcc" would be a nice convention too.
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.
The fact that lots of people want to comment their package.json file and can’t easily due to Crockford’s decision does not mean that Crockford’s argument is nonsense. Crockford’s argument is not that there shouldn’t be comments in JSON because no one would want to use them. And again, I would also like to have comments in JSON.
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 with the fact that since it's not in the standard, you never really know if the file you're creating may be read by something that won't strip comments. It's the worst of all possible worlds in my opinion, with 0 benefit.
Earlier quoted context omitted.
JSON doesn’t specify its numeric types: the mapping of a string of digits to concrete numeric types is implementation-defined: so, JSON doesn’t need specific syntax for BigInts or arbitrary-precision decimals.
Current parsers cannot start returning BigInts instead of numbers without that being a breaking change. And I'm not sure anyone wants a format where the result may change types based on the size of the number, especially for languages where arbitrary precision types are not compatible with other numbers.
Current parsers aren't uniform here. Since the JSON spec is silent on what post-parsing format is used for numbers, each parser is free to do whatever makes sense in the context of the host language. I reckon you'll find some JSON parsers use bigints already, especially in languages with first-class bigint support (such as various Lisp dialects)
> And I'm not sure anyone wants a format where the result may change types based on the size of the number
That's nothing to do with the format, that's to do with the parser. Some parsers already do exactly that – use an integer type for numbers that are integers, use a floating point type for numbers that contain decimal points
Earlier quoted context omitted.
https://en.wiktionary.org/wiki/RTFA
I'm aware, thanks. I wanted to see if CameronNemo would spell it out. I'd like to point out the HN Guidelines: https://news.ycombinator.com/newsguidelines.html > Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that." Even putting aside what "F" stands for, this means that comments like TFA or RTFA are not in the spiri…
That's exactly what the parent wrote, so he's totally fine with respect to the HN Guidelines.
To quote: "The author reviewed most prior art in TFA.".
> Yes, Doug Crockford deliberately removed comments from JSON but people keep putting them back in. If we’re going to have comment-enriched JSON (e.g. for human-editable configuration files), we might as well have a standard one. The text "deliberately removed comments from JSON" links to https://web.archive.org/web/20150105080225if_/https://plus.g... where Doug not only explains the reason, but also a solution which…
Just because he had a reason to give doesn't mean it wasn't a bad reason. His stated reasoning failed with hindsight.
(a) People already do what he thought was preventing (custom parser behavior) by removing comments, (so his choice failed to prevent what he wanted to prevent)
(b) people have already created dozens of JSON parser variants that accept comments, because we really want those. And not just some niche devs - Microsoft and dozens of other big companies have tools that accept JSON + dangling commas + extra comments (so his choice was second-guessed and bypassed anyway, just in ad-hoc ways instead of a better universal one).
It wasn't his place to define whether we get comments or not based on some potential parser abuse. But he did it, and now we're stuck with that decision...
Earlier quoted context omitted.
Crockford regularly displays a stunning degree of tunnel vision. Without a standard format for comments, you have no reason whatsoever to expect the ad-hoc comments in a JSON file made by anyone who isn't you to be styled like JavaScript comments. And if your response is "then everyone needs to use JavaScript-style comments", well, TA-DA, you've just added comments to the spec. You can't have it both ways. > It's imp…
I wish JSON supported comments, but I don’t really understand your criticism. You say: > Without a standard format for comments, you have no reason whatsoever to expect the ad-hoc comments in a JSON file made by anyone who isn't you to be styled like JavaScript comments. But, since comments are not supported in JSON, you can expect JSON from external sources to contain no comments whatsoever. That’s precisely Crockfo…
You can expect it, and then you'd be suprised when they do.
See people really want/need comments, and they're gonna implement them anyway in dozens of little parsers/libs, and you're gonna have to deal with files having them anyway...
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.
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...
I did this to support hand-writing game data in JSON (e.g. monster stats, campaign dialog scripts) and then converting it to MessagePack at build time [2]. This gives you very high simplicity (no schemas) and excellent performance.
I would like to see why the author chose to do yet another format, vs adopt JSON5.