11 ms·
I think it allows for too much. I was glad that JSON only supports double-quoted strings. It is a feature that removes discussions about which quotes to use. Or
by nikeee 2y ago
I think it allows for too much. I was glad that JSON only supports double-quoted strings. It is a feature that removes discussions about which quotes to use. Or even whether to use quotes at all (we still need them for keys with colons or minus in it, so what gives?).
The only thing that JSON is really missing are comments and trailing commas. I use JSONC for that. It's what VSC uses for the config format and it works.
- numbsafari 2y agoAllowing for leading decimals without a preceding zero also seems like shifting a whole class of errors right.
- appplication 2y agoAs a data guy I find myself running into JSONL a fair bit. It was surprising to me that it’s not supported in the vanilla spec.
- compootr 2y agoas a student experimenting with millions of records of data, its pretty nice!
- nigeltao 2y agoJWCC literally stands for JSON With Commas and Comments. JWCC is also what Tailscale call HuJSON, as in "JSON for Humans", which as amusingly also what json5 claims to be. https://github.com/tailscale/hujson https://github.com/tailscale/hujson
- Pxtl 2y ago> The only thing that JSON is really missing are comments and trailing commas. I use JSONC for that. It's what VSC uses for the config format and it works. I disagree. Human-friendy multiline strings aren't really optional for a serialization format that will inevitably also be used as a config format sometimes because those are the same problem.
- simoneau 2y agoSomeone just needs to write “JSON5: The Good Parts” and an aggressive linter to enforce it.
- catlifeonmars 2y agoWhy not just a parser? Should be easy enough.
- hippospark 2y agoAlso take a look at ASON [1]. ASON is a data format that evolved from JSON, introducing strong data typing and support for variant types. [^1] https://github.com/hemashushu/ason https://github.com/hemashushu/ason
- AdieuToLogic 2y ago> The only thing that JSON is really missing are comments and trailing commas. I use JSONC for that. YAML[0] supports JSON formatted resources and octothorpe ('#') comments as well. I didn't see anything in the spec specifically allowing for trailing commas however. Here is an exemplar using the Ruby YAML module: #!/usr/bin/ruby require 'yaml' puts YAML.load( %/ # YAML is a strict superset of JSON, which # means supporting octothorpe end-of-line # comments is supported in JSON formatted # YAML if and only if the content is multi-line # formatted as well (like this example). { # This is valid YAML! "foo" : "bar" } / ) 0 - https://yaml.org/spec/1.2.2/ https://yaml.org/spec/1.2.2/
- ratorx 2y agoWhilst YAML is an option, if the choice is between having the unnecessary extra features of JSON5 or YAML, JSON5 seems like the clear winner. Allowing multiple types of quotes may be an unnecessary feature but it is a clear lesser evil compared to the mountain of footguns that YAML brings with it.
- AdieuToLogic 2y agoHow does defining a YAML resource strictly in terms of well-formed JSON + octothorpe comments introduce "the mountain of footguns that YAML brings with it"?
- ratorx 2y agoIt doesn’t, quoting strings does solve almost all issues, but it does leave potential footguns for the future. If you don’t enforce it, in the future the “subset of YAML” property might get weaker, especially if someone else is modifying the config. If you treat config files the same as code, then using a safe subset of YAML is the same as using a safe subset of C. It is theoretically doable, but without extensive safeguards, someone will eventually slip up.
- nine_k 2y agoThe problem of yaml is that it allows too much. It allows unquoted strings, and those can be interpreted by the parser as numbers, timestamps, booleans, etc. This is a source of many fooguns. Use of indentation to denote nesting can sometimes be an anti-feature, too, because while using that the format does not provide a way to make certain that the entire stream has been read (parens balanced). This may lead to problems or even exploits. Pure JSON is so painful for human consumption though, I willingly choose yaml if it's the only alternative. JSON5 may indeed be a sweet spot between human-friendliness and lack of nasty surprises.
- n144q 2y ago> the only thing that JSON is really missing Depending what you use JSON for, "Numbers may be IEEE 754 positive infinity, negative infinity, and NaN." could be a huge plus.
- 404mm 2y agoExactly! Trailing commas (for cleaner commits) and comments are the only pain points I ever felt. On the other hand: > leadingDecimalPoint: .8675309 This is just lazy. Can we discuss in depth how much time you saved by skipping the “0” in favor of lesser readability? > andTrailing: 8675309., This doesn’t mean anything to me.
- _blk 2y agoI never understood leading dot until I understood that native speakers indeed say ".3" (point three). Trailing makes it a floating point type instead of an integer
- papercrane 2y agoTrailing to signal a floating point seems like to niche of a use case to me. Generally it's best to treat every JSON number literal as a 64-bit float anyway for the sake of interoperability.
- SV_BubbleTime 2y agoRight, you guys say like “naught point three”… sounds just as weird to us as ours does to you. Still… I can be required to put a zero in, read 0.3, and still think “that’s point three”.
- 404mm 2y agoIt became quite normal for me to write 0.3 and read it as “point three”. I do agree that the English language makes it less awkward to just skip the zero. It leaves very little room for confusion.
- xelamonster 2y agoWell what's more readable, .8675309 that is understood to have an implicit zero, or the parser giving up and unexpectedly making it a string? Maybe it's not your preference but I can't see any problem with making this more robust. The trailing one is strange to me but leaving off a leading zero isn't unusual at all for written numbers in my experience.
- selcuka 2y ago> The only thing that JSON is really missing are comments and trailing commas. The reason JSON doesn't have comments [1]: I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I know that the lack of comments makes some people sad, but it shouldn't. Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser. [1] http://archive.today/8FWsA http://archive.today/8FWsA
- SV_BubbleTime 2y agoAnd that is fine reasoning, the workaround is not for me… but the larger issue is an inventor kneecapping something by stating how you should use it. It’s not like there isn’t another side to this argument.
- KPGv2 2y ago> the larger issue is an inventor kneecapping something by stating how you should use it This isn't kneecapping something any more than an inventor requiring programmers in a new language use types, or not use types, whichever the inventor deems preferable. He invented a thing. He declared how the thing is constructed. That's not kneecapping. That's just defining a thing.
- Brian_K_White 2y agoIt is kneecapped. He invented a thing and left out a well known and understood core function required in the problem space, deliberately, not through oversight. That's what makes it kneecapping. The whole useful thing, ie the idea of a data format, including both knees (ie all the basic features any such thing needs) was there. The concept and necessity of annotation was a well known thing by then, and indeed he knew of it himself too, said so himself, and actively removed one functioning knee from that whole, to produce only the kneecapped thing. He defined a kneecapped thing. Or he kneecapped the design. Whichever way you want to say it. The difference would be if it was 40 years earlier and you are taking the fist stab at designing any kind of data format and comments just never occurred to you yet. This is more like making a new programming language and deciding that it shall not have one of the basic math operators. If you need to multiply, tough shit, do it some other way. Just pipe it through JSMulti.
- nox101 2y agoJSONC is fine but VCS should have named its configuration files settings.jsonc since the files are not JSON and will not be parsed by JSON parsers.
- xelamonster 2y agoI'm not a fan of forcing single or double quotes because escape codes are such a pain to deal with and to me make things significantly harder to read than an inconsistent quoting style ever could.
- thayne 2y ago> The only thing that JSON is really missing are comments and trailing commas. And multi-line strings. You don't always need that, but when you do, it's absence is very painful.
- stkdump 2y agoAgreed. The workaround (arrays of strings) isn't great as it means an extra transformation has to be done between the reader and the usage. I would go so far as to say this is more important than comments.
- yread 2y agoI just add another property with noncolliding name as a comment. "//key":"this is here so that foo bars", "key":"value", valid JSON. Most software handles extra propertiesjust fine
- taeric 2y agoJSON only allowing double quotes is something I have grown to not care about, but as someone that was using JavaScript object literals before JSON became a thing, I confess I do not understand why it is an advantage? If you were at a place where it was a heavy discussion on what quote to use, I'm forced to think there were deeper cultural issues at play? Don't get me wrong, the ubiquity of JSON speaks for itself and is the reason to use it. But, to say it has tangible benefits feels very dishonest.
- Cthulhu_ 2y agoThe choice of single vs double quotes means you can use single quotes if the contents contain a double quote and vice-versa. With JSON containing shell scripts (looking at package.json scripts) that's a valuable addon imo.