Hacker News Reader

Hacker News

Comment by 404mm | Hacker News Reader

Parent Full thread

404mm

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.

View on HN

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.

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

I think if we start applying that rationale we could skip a lot of steps and just move everything over to YAML.

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.

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.

I don't know what to tell you, you seem to be taking a black-or-white approach here of extremes. Like anything that isn't limited to exactly one way of expressing it is a slippery slope to YAML. It's not.

JSON5 is literally exactly JavaScript notation, which tons of people are familiar with. On the other hand, I don't know any programming languages that use strings without quotes or delimiters. (And of course, their existing in YAML is widely recognized as a major source of confusion.)

And in your example, there isn't parsing ambiguity but there would be change ambiguity when you alter abc (without quotes) to 123, because it changes its type.

I'm not aware of any change-ambiguity situations in JavaScript/JSON5 like that? In Python 5 and 5. are different types, but not in JavaScript or JSON.

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

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.

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

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.

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/

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.

Postel's Law was a bad idea.

https://datatracker.ietf.org/doc/html/draft-thomson-postel-w...

'"bug for bug" compatible'

Good reference! Turns out this internet draft has been turned into an official, informational RFC:

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.

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.

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.

> 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

Reply on news.ycombinator.com