5 ms·

Exactly! Trailing commas (for cleaner commits) and comments are the only pain points I ever felt. On the other hand: > leadingDecimalPoint: .8675309 This is

by 404mm 2y ago

Exactly! 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 ago
I 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 ago
  Trailing 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 ago
  Right, 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 ago
    It 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 ago
Well 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.
- 404mm 2y ago
  IMO the implicit zero is just as much an issue in regular written form. The period could be overlooked quite easily, but seeing a leading 0, one will know what’s really going on. How could the parser see it as a string? This is not YAML and JSON5 still requires quotation marks.
- The_Colonel 2y ago
  > Well what's more readable, .8675309 that is understood to have an implicit zero Is it universally understood? I think it's a US / English thing. In my country I've never seen numbers written in this way and many people would not "parse" it mentally as 0.8675309
  - efitz 2y ago
    [flagged]
    - The_Colonel 2y ago
      What an extreme reaction. Many people would not be able to parse it since they've never seen a number written in this way, but you immediately write them off as assholes. Wow.
      - efitz 2y ago
        It will look funny to many people but they will be able to interpret it. Remember that this thread is in the context of whether to be strict or relaxed in a specific file syntax for files intended to be authored by humans.
        The_Colonel 2y ago
        > It will look funny to many people but they will be able to interpret it. You're still approaching this with the background knowledge of what this is. If you've never seen this, you can only guess, and there are a couple of options. I've been terminally online for the better part of the last 2 decades, yet I've seen this way of writing for the first time only ~5 year ago or so, and I still remember simply not knowing what it is. The first reaction is that it's simply a typo - the author mistyped - the dot should have been a digit or perhaps not be there at all.
efitz 2y ago
It’s not about readability, it’s being realistic about other humans and making software robust in the presence of common, trivial, unambiguous “errors”. Reference: Postel’s Law https://www.laws-of-software.com/laws/postel/ https://www.laws-of-software.com/laws/postel/
- wvh 2y ago
  Arguably, if there's ambivalence about numbers or other core structures or doubt about the intent, the correct thing to do is to return an error and not try to guess. The point of an error bubbling up is asking for clarity from the end-user, while guessing will lead to random results in ways that can not be detected or corrected anymore later on in the process. I think Postel's law was intended to apply to alternative implementations of machine-level protocols. That's not to say that I don't agree that it might be better if JSON implementations would allow trailing commas, which is unlikely to lead to semantic ambiguities. That's too late now though, unless a new JSON to rule them all would appear and we would all agree on that new spec.
- int_19h 2y ago
  Postel's Law was a bad idea. https://datatracker.ietf.org/doc/html/draft-thomson-postel-was-wrong-00 https://datatracker.ietf.org/doc/html/draft-thomson-postel-w...
  - cwmoore 2y ago
    '"bug for bug" compatible'
  - smarks 2y ago
    Good reference! Turns out this internet draft has been turned into an official, informational RFC: https://datatracker.ietf.org/doc/html/rfc9413 https://datatracker.ietf.org/doc/html/rfc9413 I don't think Postel's Law was necessarily a bad idea, in its time and context. However it seems to have fallen into usage as an argument-ender. This RFC is a useful antidote to that.
SkyBelow 2y ago
If we consider sigfigs, then isn't 100 and 100. two different numbers given one has a single significant digit and the other has 3? For 101 and 101. it doesn't matter because both have 3 significant digits. Then again, one may argue that it is better to write 1e2 and 1.00e2 instead of 100 and 100.. It also avoids the weirdness of the double period if the number with a dot ends a sentence. On a personal level, I also don't like ending a number with a . because my brain immediately parses it as a sentence ender and it interrupts my reading flow.
crazygringo 2y ago
It has nothing to do with laziness in typing. It's just not wanting to keep track of more rules. If you've only ever used languages where a leading decimal point is allowed, it's a pain point to suddenly have to remember that it isn't here, and for no obviously intuitive reason. It's about wanting to avoid unnecessary conceptual friction. Not lazy keyboard usage. (Heck, your second example uses an extra keystroke. And it's perfectly readable to me, based on the languages I use.)
- nucleardog 2y ago
  I think if we start applying that rationale we could skip a lot of steps and just move everything over to YAML.
  - crazygringo 2y ago
    No because YAML is full of ambiguity. JSON5 is not. There's something to be said for being flexible in your inputs when they are non-ambiguous. Particularly when dealing with files written by hand. There's no virtue in imposing overly strict syntax when it serves no human purpose. That's trying to alter people to fit machines, rather than altering machines to fit people.
    - nucleardog 2y ago
      Yeah, and we could easily say that any property value without a comma, closing bracket, or closing brace; that doesn't follow the format for numeric literals; and isn't the literal value 'true' or 'false' doesn't need to be quoted when part of a value and will implicitly be a string. This adds no ambiguity and some people are used to writing their string literals without any extra quotes, why add the extra cognitive load of having to remember to use quotes? Wouldn't it be nice to write `user: { type: admin, name: Bob }`? This seems like exactly how we ended up with YAML-and-the-kitchen-sink. For a spec like this, things should need a better justification than that. Everything starts at -100 points. How does this feature justify the additional complexity in the spec, to the users, and to the people trying to implement this? How does it justify increasing the opportunity for creating subtly incompatible parsers? Or, if a goal of JSON is not to be simple and interoperable, then I fail to see how it's not just YAML but 5 or 10 years behind the curve, so we may as well skip a bunch of hassle and move to YAML and start fixing the bugs we've got there rather than creating new ones here.

by 404mm 2y ago

_blk 2y ago

I 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 ago
Trailing 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 ago
Right, 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 ago
  It 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 ago

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

404mm 2y ago
IMO the implicit zero is just as much an issue in regular written form. The period could be overlooked quite easily, but seeing a leading 0, one will know what’s really going on. How could the parser see it as a string? This is not YAML and JSON5 still requires quotation marks.
The_Colonel 2y ago
> Well what's more readable, .8675309 that is understood to have an implicit zero Is it universally understood? I think it's a US / English thing. In my country I've never seen numbers written in this way and many people would not "parse" it mentally as 0.8675309
- efitz 2y ago
  [flagged]
  - The_Colonel 2y ago
    What an extreme reaction. Many people would not be able to parse it since they've never seen a number written in this way, but you immediately write them off as assholes. Wow.
    - efitz 2y ago
      It will look funny to many people but they will be able to interpret it. Remember that this thread is in the context of whether to be strict or relaxed in a specific file syntax for files intended to be authored by humans.
      - The_Colonel 2y ago
        > It will look funny to many people but they will be able to interpret it. You're still approaching this with the background knowledge of what this is. If you've never seen this, you can only guess, and there are a couple of options. I've been terminally online for the better part of the last 2 decades, yet I've seen this way of writing for the first time only ~5 year ago or so, and I still remember simply not knowing what it is. The first reaction is that it's simply a typo - the author mistyped - the dot should have been a digit or perhaps not be there at all.

efitz 2y ago

It’s not about readability, it’s being realistic about other humans and making software robust in the presence of common, trivial, unambiguous “errors”. Reference: Postel’s Law https://www.laws-of-software.com/laws/postel/ https://www.laws-of-software.com/laws/postel/

wvh 2y ago
Arguably, if there's ambivalence about numbers or other core structures or doubt about the intent, the correct thing to do is to return an error and not try to guess. The point of an error bubbling up is asking for clarity from the end-user, while guessing will lead to random results in ways that can not be detected or corrected anymore later on in the process. I think Postel's law was intended to apply to alternative implementations of machine-level protocols. That's not to say that I don't agree that it might be better if JSON implementations would allow trailing commas, which is unlikely to lead to semantic ambiguities. That's too late now though, unless a new JSON to rule them all would appear and we would all agree on that new spec.
int_19h 2y ago
Postel's Law was a bad idea. https://datatracker.ietf.org/doc/html/draft-thomson-postel-was-wrong-00 https://datatracker.ietf.org/doc/html/draft-thomson-postel-w...
- cwmoore 2y ago
  '"bug for bug" compatible'
- smarks 2y ago
  Good reference! Turns out this internet draft has been turned into an official, informational RFC: https://datatracker.ietf.org/doc/html/rfc9413 https://datatracker.ietf.org/doc/html/rfc9413 I don't think Postel's Law was necessarily a bad idea, in its time and context. However it seems to have fallen into usage as an argument-ender. This RFC is a useful antidote to that.

SkyBelow 2y ago

If we consider sigfigs, then isn't 100 and 100. two different numbers given one has a single significant digit and the other has 3? For 101 and 101. it doesn't matter because both have 3 significant digits. Then again, one may argue that it is better to write 1e2 and 1.00e2 instead of 100 and 100.. It also avoids the weirdness of the double period if the number with a dot ends a sentence. On a personal level, I also don't like ending a number with a . because my brain immediately parses it as a sentence ender and it interrupts my reading flow.

crazygringo 2y ago

It has nothing to do with laziness in typing. It's just not wanting to keep track of more rules. If you've only ever used languages where a leading decimal point is allowed, it's a pain point to suddenly have to remember that it isn't here, and for no obviously intuitive reason. It's about wanting to avoid unnecessary conceptual friction. Not lazy keyboard usage. (Heck, your second example uses an extra keystroke. And it's perfectly readable to me, based on the languages I use.)

nucleardog 2y ago
I think if we start applying that rationale we could skip a lot of steps and just move everything over to YAML.
- crazygringo 2y ago
  No because YAML is full of ambiguity. JSON5 is not. There's something to be said for being flexible in your inputs when they are non-ambiguous. Particularly when dealing with files written by hand. There's no virtue in imposing overly strict syntax when it serves no human purpose. That's trying to alter people to fit machines, rather than altering machines to fit people.
  - nucleardog 2y ago
    Yeah, and we could easily say that any property value without a comma, closing bracket, or closing brace; that doesn't follow the format for numeric literals; and isn't the literal value 'true' or 'false' doesn't need to be quoted when part of a value and will implicitly be a string. This adds no ambiguity and some people are used to writing their string literals without any extra quotes, why add the extra cognitive load of having to remember to use quotes? Wouldn't it be nice to write `user: { type: admin, name: Bob }`? This seems like exactly how we ended up with YAML-and-the-kitchen-sink. For a spec like this, things should need a better justification than that. Everything starts at -100 points. How does this feature justify the additional complexity in the spec, to the users, and to the people trying to implement this? How does it justify increasing the opportunity for creating subtly incompatible parsers? Or, if a goal of JSON is not to be simple and interoperable, then I fail to see how it's not just YAML but 5 or 10 years behind the curve, so we may as well skip a bunch of hassle and move to YAML and start fixing the bugs we've got there rather than creating new ones here.