3 ms·

Postel's Law and the Three Ring Circus

58 points by zdw 2y ago

ChrisMarshallNY 2y ago
> I encourage maintainers to reject user feedback that is much more properly directed to some commercial software vendor who has not implemented the specification correctly. Words to live by.
- cratermoon 2y ago
  If only we'd had that attitude in the 90s when html parsers proliferated. Instead we got tag soup and well, whatever this is: https://github.com/WebKit/WebKit/blob/main/Source/WebCore/page/Quirks.cpp https://github.com/WebKit/WebKit/blob/main/Source/WebCore/pa...
  - ChrisMarshallNY 2y ago
    Ah, good ol' Quirks Mode. Memories...
andrewstuart 2y ago
A very wordy post, no really sure the point of it. What I can say though is that Postel's Law is a pile of rubbish that sounds sage and wise and leads to software problems. Make software clearly defined in what you output and what you accept. Clear and strongly typed data interfaces help everyone get along with minimal bugs. Being “liberal in what you accept” is a recipe for errors. Ref: The Harmful Consequences of the Robustness Principle https://datatracker.ietf.org/doc/draft-thomson-postel-was-wrong/ https://datatracker.ietf.org/doc/draft-thomson-postel-was-wr...
- prepend 2y ago
  I think this may be a scissor statement for developers [0] as people seem to really be on one side or the other. I remember years ago I wrote a Java package to sit on top of DOMs and let you query and manipulate in memory. People at my company liked it and so maybe like 20-30 people used it as the in memory store for passing info around this workflow engine. Anyway, I assumed you would always have a DOM or some Nodes and if you didn’t, allowed null pointer exceptions to throw in the right places (what I thought was right). Some people liked starting with null and populating later and my logic would blow them up. My response was “fix your code, don’t do that.” My package was clearly documented for what to do and when. But one day another senior dev came to me to plead the case for some mids who were writing all this extra code to prehandle those nulls. I still didn’t change my package because I thought it was most efficient to use it properly than to add in extra logic that sort of broke the interface. I did tell them that I welcomes a pull request to add the functionality. Looking back, I wish I had been more liberal in what I accepted because it was causing a lot of emotional pain by people sort of lobbying others. “Minimal bugs” depends on where in the stack you look. [0] https://slatestarcodex.com/2018/10/30/sort-by-controversial/ https://slatestarcodex.com/2018/10/30/sort-by-controversial/
  - shadowgovt 2y ago
    All nothings are not equal. http://thecodelesscode.com/case/6 http://thecodelesscode.com/case/6
- chrismorgan 2y ago
  > https://datatracker.ietf.org/doc/draft-thomson-postel-was-wrong/ https://datatracker.ietf.org/doc/draft-thomson-postel-was-wr... The original draft had an excellent name, and expressed a strong position. It was picked up and the consensus was published as RFC 9413 in mid-2023.
ipython 2y ago
I think there’s a temporal aspect to this. Postel’s law was the right idea at the right time. It allows for wide experimentation in the early growth curve while at the same time exploding the realistic user base (because these implementations could in large part talk to each other)
robinhouston 2y ago
I would find this argument more compelling if it were supported by examples. Although it’s easy to imagine this sort of dynamic unfolding, offhand I can’t think of any good examples of it happening with internet protocols in quite this way. On the other hand, I can immediately think of an example to the contrary: I would at least partly attribute the failure of XHTML to the fact that conforming renderers were forbidden to be liberal in what they accept, and viewers of XHTML pages would often be faced with an error message in place of the page they wanted to see, as a consequence of some minor mistake.
- austin-cheney 2y ago
  For the best case example design your code with the goal of failure and properly describing failure states for the users benefit. The success state should be a narrow exception provided the input is formatted exactly as the specification describes. This greatly lowers the acceptance criteria to test for and instead forces a greater focus on negative tests and error conditions.
- dale_glass 2y ago
  HTML is a great example in my opinion. XHTML failed because it was trying to close the barn door after the horse had bolted a decade ago. XHTML was a reaction to an existing issue: that HTML is absolutely hellish to parse to the point that in the 90s half the web officially endorsed either IE or Netscape to be used for that particular website. Not to speak of anyone actually trying to do something clever with the contents of web pages. Had XHTML worked it'd have been a huge quality of life improvement. The problem was that it was too late and that it was introduced into an ecosystem not prepared for it because everyone had long built on the assumption that you can just haphazardly generate chunks of HTML and insert them into the middle of other chunks of HTML. Also, XHTML's error messages would probably be appreciated more today. Today we appreciate that allowing an HN poster to just drop random tags into a post is a terrible idea, so the fact that if on XHTML an user just leaves an unclosed tag the entire page fails to render, it's a good thing. It's a sign that you're doing handling of user data terribly wrong and it needs fixing post-haste. But back when XHTML showed up security was such an afterthought that barely anyone cared, and they just wanted things to work, dammit. In the end we solved it first by a bigger push on standardization because people finally got sick of it, and later by Chrome just eating the browser market.
kayo_20211030 2y ago
Perhaps the specification is irrelevant, and it would be better to look at the actors' goals and incentives. Using the OP's example As a first approximation, it's reasonable to say that the goal of the closed source software's producer is to make money, and the goal of the open source software's provider is to have people use it. The closed source software's author has no incentive to continue to follow the specification unless it advances the goal of making money; and the open source software's authors have no incentive to reject deviations from the specification if the result is a drop in usage. Postel's law still holds even in this asymmetric situation because that's where the incentives are.
akoboldfrying 2y ago
Agree, but I don't think the incentives align as claimed -- with bad (lax) producers being usually commercial, and good (strict) consumers being usually open source. I think anyone who has already made a thing in program X and then finds that program Y won't load that thing will tend to complain about program Y first -- both unconsciously, and also consciously (because if the bug is in X, they might need to recreate their thing, and nobody wants that). So even open source producer programs will tend to be favoured over open source consumers. The ability to complain at open source consumers is real, but I think this form of pain probably reached its apex in commercial software: backwards compatibility in Windows. Raymond Chen's blog The Old New Thing details the absolutely insane lengths Windows engineers went to to keep buggy software running on new versions of Windows.
- bonoboTP 2y ago
  I immediately thought about LibreOffice and MS Office. The compatibility has improved a lot, but things do break. And it is a showstopper for many users who receive documents by other people made in MS Office, or request MS Office files. It don't think the compatibility has to be 100% perfect, but visible breakage is an absolute showstopper for many users. I've recommended using LibreOffice to a small family business, but when existing documents showed up visually misaligned, they had to switch back. In this case it really doesn't matter who is to blame. For normal people who have things to do, the only thing that matters is whether they get the results they need or not. 99% won't complain to either MS or LibreOffice, they will just throw out the open product and just pay the commercial one and move on with their business. Similarly, maybe your new browser fully and faithfully implements all the web standards down to the letter. But if it doesn't load Instagram, or Reddit or whatever popular site, then users won't care whether the blame lies with the website or the browser. They don't even have the granularity required for that in their mental model to distinguish these things. They see: when using Chrome, things work, when using the alternative browser, things are broken. Conclusion: use Chrome. It's like this in many cases. You can stomp your foot and stand up for rigor or whatever, but it won't change reality that you merely insist that it changes.
shadowgovt 2y ago
Good essay. Counter-argument: the Python setuptools outage this week (https://github.com/pypa/setuptools/issues/4919 https://github.com/pypa/setuptools/issues/4919) was more-or-less an exercise in ignoring Postel's Law to the peril of the project. Python (as an ecosystem) had historically allowed hyphens and underscores in the `setup.cfg` file. The setuptools project deprecated this behavior years ago. This week, they tried to act on the deprecation and blew up multiple high-use dependencies. The best way to avoid this issue would have been to never deprecate it in the first place; treating hyphen and underscore as the same had minimal impact on the codebase and made setuptools more compatible with other Python tooling.
- bonoboTP 2y ago
  Great example for minor cosmetic changes that pointlessly break stuff. I see this a lot in Python libraries, seems to be a culture thing. Renaming arguments, moving stuff into different subpackages, just so much churn. Yeah, I get it, it may be slightly more consistent, or feels cleaner, but in many cases it's quite subjective but library authors seem quite prone to just deprecate it, then deprecate the new version again soon after... It's like they don't realize that there's code out there that uses it. This is why code "rots". When I complain about software churn and the waste of effort to keep existing code functional, people point to security vulnerabilities etc., but that should be possible to do without a bunch of pointless renames and refactors. Case in point: `collections.MutableMapping` was moved to `collections.abc.MutableMapping` in Python 3.10, breaking a bunch of nice libraries that provide useful data structures. And why? Because it looked more tidy and conceptually comforting for some Python devs. https://stackoverflow.com/questions/70870041/cannot-import-name-mutablemapping-from-collections https://stackoverflow.com/questions/70870041/cannot-import-n... This can be super demotivating. Someone at some point in their lives made a useful tool, but then moved on, maybe they were a grad student at the time, and now they have a family, etc. And we are cut off from their contributions because they can't keep up with slightly adjusting the code to the whims of language and library authors every month or two. Some other languages are much better about not breaking existing code, e.g. Java.
  - shadowgovt 2y ago
roenxi 2y ago
> Ecosystems that adhere to Postel’s Law therefore experience a one way ratchet: consumers must accept more and more deviations from the specifications, and because consumers accept the deviations, producers are never forced (or incentivized) to themselves become stricter in following the specifications He's not wrong but this isn't exactly true - it is sometimes the case that protocols will incentive conformity even while accepting liberally. As a basic example, not failing on an unknown tag - say we have a system with emoji and if we sees an emoji tag we don't recognise we print it in text. This is liberal in what it accepts because if someone typos an emoji it is still accepted, but they are nonetheless incentivised to get the spelling right because they were trying to get an emoji to display. The same principle means that most comemnts on HN are spelled correctly or close too. So the truly inspired protocol will attach subtle costs to non-conforming emitters, but nonetheless tolerate them and allow them to participate in a network.
phkahler 2y ago
I think there's a related phenomenon that we see all the time in automotive circles. A vehicle manufacturer (OEM) needs a new thing, so a supplier develops it in cooperation with them. Great! The requirements were vague and all that, but you arrive at a solution that works. The supplier documents the performance in a product specification stating what it can do and under what conditions. Great! Next the OEM asks for quotes on next gen, and also goes to other suppliers to see if they can provide at lower cost. The OEM uses your product spec as a requirements document and this is where it all goes to shit (a product specification is not a requirements document). They no longer know what they need, but the know what they have and they want "same or better" next time. Over time this can lead to absurd specs and increased complexity to meet them. Sometimes a competitor comes in with a cheaper version and the OEM gets excited based on price and all the actual requirements might get revisited because the cheaper part is out of spec (to save cost). This seems similar to the Postel's Law thing. If you produce to spec but accept things out of spec, the ecosystem will unofficially change the spec to what's actually out there. Then people will re-apply Postel's Law with a wider spec on what you produce and even wider on what you accept. Eventually you end up with a complex mess, but in this case it's a widening spec where in the automotive example it's usually a narrowing spec.
mhb 2y ago
This is an example of the broader explanation of why we can't have nice things. In a high trust society, condiment packets are free with the expectation that customers will be reasonable in their use. Then customers take advantage of this to use the free ketchup to fill a wading pool.
zombot 2y ago
When "liberal" means to permit deviations from the relevant specification, then normalization of deviance is a predictable outcome. I never interpreted "liberal" that way, but rather as accepting multiple input formats, and each one has to be used correctly. You cannot parse sensibly when you don't know by what spec or syntax.
zamfi 2y ago
As a counterpoint, Postel's Law as implemented in other domains has been spectacularly successful. One classic example is in transistor networks: each node in a network (think interconnected logic gates, but at the analog level) accepts a wider range of voltages as "high" and "low (i.e., 1- and 0-valued) than they are specified to output. In 5V logic, for example, transistors might output 5V and 0V to within 5%, but accept anything above 1.2V as "high" and below that as "low". (Sometimes called the "static discipline" and used as an example of the "robustness principle"—the other name for Postel's Law.) This is critical in these networks, but not because transistor manufacturers don't read or fully implement the spec: it's because there is invariably unavoidable noise introduced into the system, and one way to handle that is for every node to "clean up" its input to the degree that it can. It's one thing to rely on this type of clean-up to make your systems work in the face of external noise. But when you start rearchitecting your systems to operate close to this boundary—that is, you're no longer trying to meet spec, because you know some other node will clean up your mess for you—you're cooked. Because the invariable noise will now push you outside the range of what your spec's liberal input regime can tolerate, and you'll get errors. The problem isn't Postel's law. It's adverse selection / moral hazard / whatever you want to call the incentive to exploit a system's tolerance for error to improve short-term outcomes for the exploiter but at long-term cost to system stability.
- kurthr 2y ago
  Complex systems are by definition high dimensional. We often build them with fault tolerance and soft "failure modes" to prevent catastrophic events. However, the dimensionality and complexity mean that almost every sufficiently complex system is ALWAYS running in a "degraded" mode. However once this is normalized, the failure when it occurs is usually catastrophic, and determining proximate cause (often work grouped as "root cause"), much less fixing it, is made even more difficult. The rapid exponential growth in complexity seen in semi over many decades has created guardrails (eg horrific yield/field failures) in modeling and verification that prevent a lot of problems. I do worry that as Moore slows (multi-chip modules are not Dennard scaling) we will lose some of this anti-fragility. Of course the other side of this is Muntzing (the removal of any part that doesn't cause immediate failure): https://en.wikipedia.org/wiki/Muntzing https://en.wikipedia.org/wiki/Muntzing
gpvos 2y ago
I think a fair amount of leniency with input is a good thing. The problem starts when you start to increase your leniency in response to someone else's out-of-spec output. A nice thing of open source projects is that they are freeer to call out other software that produces out-of-spec output, and I would encourage them to do so... liberally.

58 points by zdw 2y ago

> I encourage maintainers to reject user feedback that is much more properly directed to some commercial software vendor who has not implemented the specification correctly. Words to live by.

cratermoon 2y ago
If only we'd had that attitude in the 90s when html parsers proliferated. Instead we got tag soup and well, whatever this is: https://github.com/WebKit/WebKit/blob/main/Source/WebCore/page/Quirks.cpp https://github.com/WebKit/WebKit/blob/main/Source/WebCore/pa...
- ChrisMarshallNY 2y ago
  Ah, good ol' Quirks Mode. Memories...

andrewstuart 2y ago

A very wordy post, no really sure the point of it. What I can say though is that Postel's Law is a pile of rubbish that sounds sage and wise and leads to software problems. Make software clearly defined in what you output and what you accept. Clear and strongly typed data interfaces help everyone get along with minimal bugs. Being “liberal in what you accept” is a recipe for errors. Ref: The Harmful Consequences of the Robustness Principle https://datatracker.ietf.org/doc/draft-thomson-postel-was-wrong/ https://datatracker.ietf.org/doc/draft-thomson-postel-was-wr...

prepend 2y ago
I think this may be a scissor statement for developers [0] as people seem to really be on one side or the other. I remember years ago I wrote a Java package to sit on top of DOMs and let you query and manipulate in memory. People at my company liked it and so maybe like 20-30 people used it as the in memory store for passing info around this workflow engine. Anyway, I assumed you would always have a DOM or some Nodes and if you didn’t, allowed null pointer exceptions to throw in the right places (what I thought was right). Some people liked starting with null and populating later and my logic would blow them up. My response was “fix your code, don’t do that.” My package was clearly documented for what to do and when. But one day another senior dev came to me to plead the case for some mids who were writing all this extra code to prehandle those nulls. I still didn’t change my package because I thought it was most efficient to use it properly than to add in extra logic that sort of broke the interface. I did tell them that I welcomes a pull request to add the functionality. Looking back, I wish I had been more liberal in what I accepted because it was causing a lot of emotional pain by people sort of lobbying others. “Minimal bugs” depends on where in the stack you look. [0] https://slatestarcodex.com/2018/10/30/sort-by-controversial/ https://slatestarcodex.com/2018/10/30/sort-by-controversial/
- shadowgovt 2y ago
  All nothings are not equal. http://thecodelesscode.com/case/6 http://thecodelesscode.com/case/6
chrismorgan 2y ago
> https://datatracker.ietf.org/doc/draft-thomson-postel-was-wrong/ https://datatracker.ietf.org/doc/draft-thomson-postel-was-wr... The original draft had an excellent name, and expressed a strong position. It was picked up and the consensus was published as RFC 9413 in mid-2023.

ipython 2y ago

I think there’s a temporal aspect to this. Postel’s law was the right idea at the right time. It allows for wide experimentation in the early growth curve while at the same time exploding the realistic user base (because these implementations could in large part talk to each other)

robinhouston 2y ago

I would find this argument more compelling if it were supported by examples. Although it’s easy to imagine this sort of dynamic unfolding, offhand I can’t think of any good examples of it happening with internet protocols in quite this way. On the other hand, I can immediately think of an example to the contrary: I would at least partly attribute the failure of XHTML to the fact that conforming renderers were forbidden to be liberal in what they accept, and viewers of XHTML pages would often be faced with an error message in place of the page they wanted to see, as a consequence of some minor mistake.

austin-cheney 2y ago
For the best case example design your code with the goal of failure and properly describing failure states for the users benefit. The success state should be a narrow exception provided the input is formatted exactly as the specification describes. This greatly lowers the acceptance criteria to test for and instead forces a greater focus on negative tests and error conditions.
dale_glass 2y ago
HTML is a great example in my opinion. XHTML failed because it was trying to close the barn door after the horse had bolted a decade ago. XHTML was a reaction to an existing issue: that HTML is absolutely hellish to parse to the point that in the 90s half the web officially endorsed either IE or Netscape to be used for that particular website. Not to speak of anyone actually trying to do something clever with the contents of web pages. Had XHTML worked it'd have been a huge quality of life improvement. The problem was that it was too late and that it was introduced into an ecosystem not prepared for it because everyone had long built on the assumption that you can just haphazardly generate chunks of HTML and insert them into the middle of other chunks of HTML. Also, XHTML's error messages would probably be appreciated more today. Today we appreciate that allowing an HN poster to just drop random tags into a post is a terrible idea, so the fact that if on XHTML an user just leaves an unclosed tag the entire page fails to render, it's a good thing. It's a sign that you're doing handling of user data terribly wrong and it needs fixing post-haste. But back when XHTML showed up security was such an afterthought that barely anyone cared, and they just wanted things to work, dammit. In the end we solved it first by a bigger push on standardization because people finally got sick of it, and later by Chrome just eating the browser market.

kayo_20211030 2y ago

Perhaps the specification is irrelevant, and it would be better to look at the actors' goals and incentives. Using the OP's example As a first approximation, it's reasonable to say that the goal of the closed source software's producer is to make money, and the goal of the open source software's provider is to have people use it. The closed source software's author has no incentive to continue to follow the specification unless it advances the goal of making money; and the open source software's authors have no incentive to reject deviations from the specification if the result is a drop in usage. Postel's law still holds even in this asymmetric situation because that's where the incentives are.

akoboldfrying 2y ago

Agree, but I don't think the incentives align as claimed -- with bad (lax) producers being usually commercial, and good (strict) consumers being usually open source. I think anyone who has already made a thing in program X and then finds that program Y won't load that thing will tend to complain about program Y first -- both unconsciously, and also consciously (because if the bug is in X, they might need to recreate their thing, and nobody wants that). So even open source producer programs will tend to be favoured over open source consumers. The ability to complain at open source consumers is real, but I think this form of pain probably reached its apex in commercial software: backwards compatibility in Windows. Raymond Chen's blog The Old New Thing details the absolutely insane lengths Windows engineers went to to keep buggy software running on new versions of Windows.

bonoboTP 2y ago
I immediately thought about LibreOffice and MS Office. The compatibility has improved a lot, but things do break. And it is a showstopper for many users who receive documents by other people made in MS Office, or request MS Office files. It don't think the compatibility has to be 100% perfect, but visible breakage is an absolute showstopper for many users. I've recommended using LibreOffice to a small family business, but when existing documents showed up visually misaligned, they had to switch back. In this case it really doesn't matter who is to blame. For normal people who have things to do, the only thing that matters is whether they get the results they need or not. 99% won't complain to either MS or LibreOffice, they will just throw out the open product and just pay the commercial one and move on with their business. Similarly, maybe your new browser fully and faithfully implements all the web standards down to the letter. But if it doesn't load Instagram, or Reddit or whatever popular site, then users won't care whether the blame lies with the website or the browser. They don't even have the granularity required for that in their mental model to distinguish these things. They see: when using Chrome, things work, when using the alternative browser, things are broken. Conclusion: use Chrome. It's like this in many cases. You can stomp your foot and stand up for rigor or whatever, but it won't change reality that you merely insist that it changes.

shadowgovt 2y ago

Good essay. Counter-argument: the Python setuptools outage this week (https://github.com/pypa/setuptools/issues/4919 https://github.com/pypa/setuptools/issues/4919) was more-or-less an exercise in ignoring Postel's Law to the peril of the project. Python (as an ecosystem) had historically allowed hyphens and underscores in the `setup.cfg` file. The setuptools project deprecated this behavior years ago. This week, they tried to act on the deprecation and blew up multiple high-use dependencies. The best way to avoid this issue would have been to never deprecate it in the first place; treating hyphen and underscore as the same had minimal impact on the codebase and made setuptools more compatible with other Python tooling.

bonoboTP 2y ago
Great example for minor cosmetic changes that pointlessly break stuff. I see this a lot in Python libraries, seems to be a culture thing. Renaming arguments, moving stuff into different subpackages, just so much churn. Yeah, I get it, it may be slightly more consistent, or feels cleaner, but in many cases it's quite subjective but library authors seem quite prone to just deprecate it, then deprecate the new version again soon after... It's like they don't realize that there's code out there that uses it. This is why code "rots". When I complain about software churn and the waste of effort to keep existing code functional, people point to security vulnerabilities etc., but that should be possible to do without a bunch of pointless renames and refactors. Case in point: `collections.MutableMapping` was moved to `collections.abc.MutableMapping` in Python 3.10, breaking a bunch of nice libraries that provide useful data structures. And why? Because it looked more tidy and conceptually comforting for some Python devs. https://stackoverflow.com/questions/70870041/cannot-import-name-mutablemapping-from-collections https://stackoverflow.com/questions/70870041/cannot-import-n... This can be super demotivating. Someone at some point in their lives made a useful tool, but then moved on, maybe they were a grad student at the time, and now they have a family, etc. And we are cut off from their contributions because they can't keep up with slightly adjusting the code to the whims of language and library authors every month or two. Some other languages are much better about not breaking existing code, e.g. Java.
- shadowgovt 2y ago

roenxi 2y ago

> Ecosystems that adhere to Postel’s Law therefore experience a one way ratchet: consumers must accept more and more deviations from the specifications, and because consumers accept the deviations, producers are never forced (or incentivized) to themselves become stricter in following the specifications He's not wrong but this isn't exactly true - it is sometimes the case that protocols will incentive conformity even while accepting liberally. As a basic example, not failing on an unknown tag - say we have a system with emoji and if we sees an emoji tag we don't recognise we print it in text. This is liberal in what it accepts because if someone typos an emoji it is still accepted, but they are nonetheless incentivised to get the spelling right because they were trying to get an emoji to display. The same principle means that most comemnts on HN are spelled correctly or close too. So the truly inspired protocol will attach subtle costs to non-conforming emitters, but nonetheless tolerate them and allow them to participate in a network.

phkahler 2y ago

I think there's a related phenomenon that we see all the time in automotive circles. A vehicle manufacturer (OEM) needs a new thing, so a supplier develops it in cooperation with them. Great! The requirements were vague and all that, but you arrive at a solution that works. The supplier documents the performance in a product specification stating what it can do and under what conditions. Great! Next the OEM asks for quotes on next gen, and also goes to other suppliers to see if they can provide at lower cost. The OEM uses your product spec as a requirements document and this is where it all goes to shit (a product specification is not a requirements document). They no longer know what they need, but the know what they have and they want "same or better" next time. Over time this can lead to absurd specs and increased complexity to meet them. Sometimes a competitor comes in with a cheaper version and the OEM gets excited based on price and all the actual requirements might get revisited because the cheaper part is out of spec (to save cost). This seems similar to the Postel's Law thing. If you produce to spec but accept things out of spec, the ecosystem will unofficially change the spec to what's actually out there. Then people will re-apply Postel's Law with a wider spec on what you produce and even wider on what you accept. Eventually you end up with a complex mess, but in this case it's a widening spec where in the automotive example it's usually a narrowing spec.

mhb 2y ago

This is an example of the broader explanation of why we can't have nice things. In a high trust society, condiment packets are free with the expectation that customers will be reasonable in their use. Then customers take advantage of this to use the free ketchup to fill a wading pool.

zombot 2y ago

When "liberal" means to permit deviations from the relevant specification, then normalization of deviance is a predictable outcome. I never interpreted "liberal" that way, but rather as accepting multiple input formats, and each one has to be used correctly. You cannot parse sensibly when you don't know by what spec or syntax.

zamfi 2y ago

As a counterpoint, Postel's Law as implemented in other domains has been spectacularly successful. One classic example is in transistor networks: each node in a network (think interconnected logic gates, but at the analog level) accepts a wider range of voltages as "high" and "low (i.e., 1- and 0-valued) than they are specified to output. In 5V logic, for example, transistors might output 5V and 0V to within 5%, but accept anything above 1.2V as "high" and below that as "low". (Sometimes called the "static discipline" and used as an example of the "robustness principle"—the other name for Postel's Law.) This is critical in these networks, but not because transistor manufacturers don't read or fully implement the spec: it's because there is invariably unavoidable noise introduced into the system, and one way to handle that is for every node to "clean up" its input to the degree that it can. It's one thing to rely on this type of clean-up to make your systems work in the face of external noise. But when you start rearchitecting your systems to operate close to this boundary—that is, you're no longer trying to meet spec, because you know some other node will clean up your mess for you—you're cooked. Because the invariable noise will now push you outside the range of what your spec's liberal input regime can tolerate, and you'll get errors. The problem isn't Postel's law. It's adverse selection / moral hazard / whatever you want to call the incentive to exploit a system's tolerance for error to improve short-term outcomes for the exploiter but at long-term cost to system stability.

kurthr 2y ago
Complex systems are by definition high dimensional. We often build them with fault tolerance and soft "failure modes" to prevent catastrophic events. However, the dimensionality and complexity mean that almost every sufficiently complex system is ALWAYS running in a "degraded" mode. However once this is normalized, the failure when it occurs is usually catastrophic, and determining proximate cause (often work grouped as "root cause"), much less fixing it, is made even more difficult. The rapid exponential growth in complexity seen in semi over many decades has created guardrails (eg horrific yield/field failures) in modeling and verification that prevent a lot of problems. I do worry that as Moore slows (multi-chip modules are not Dennard scaling) we will lose some of this anti-fragility. Of course the other side of this is Muntzing (the removal of any part that doesn't cause immediate failure): https://en.wikipedia.org/wiki/Muntzing https://en.wikipedia.org/wiki/Muntzing

gpvos 2y ago

I think a fair amount of leniency with input is a good thing. The problem starts when you start to increase your leniency in response to someone else's out-of-spec output. A nice thing of open source projects is that they are freeer to call out other software that produces out-of-spec output, and I would encourage them to do so... liberally.