3 ms·
It’s not about readability, it’s being realistic about other humans and making software robust in the presence of common, trivial, unambiguous “errors”. Refer
by 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 agoArguably, 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 agoPostel'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 agoGood 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.