I think your view involves a bit of catastrophizing, or relying on broadly pessimistic predictions about the performance of others.
Remember, the “exception throwing” behavior involves taking the entire space of outcomes and splitting it into two things: “Normal” and “Error.” If we say this is what we ought to do in the general case, that’s basically saying this binary property is inherent in the structure of the universe.
But we know that there’s no phenomenon that can be said to actually be an “error” in some absolute, metaphysical sense. This is an arbitrary decision that we make: We choose to abort the process and destroy work in progress when the range of observations falls outside of a single threshold.
This only makes sense if we also believe that sending the possibly malformed output to the next stage in the work creates a snowball effect or an out-of-control process.
There are probably environments where that is the case. But I don’t think that it is the default case nor is it one that we’d want to engineer into our environment if we have any choice over that—which I believe we do.
If the entire pipeline is made of checkpoints where exceptions can be thrown, then if I remove an earlier checkpoint, then it could mean that more time is wasted if it is destined to be thrown at a later time. But like I mentioned in the post, I usually think this is better, because I get more data about what the malformed input/output does to later steps in the process. Also, of course, if I remove all of the checkpoints, then it’s no longer going to be wasted work.
Mapping states to a binary range is a projection which loses information. If I instead tell you, “This is what I know, this is how much I know it,” that seems better because it carries enough to still give you the projection if you wanted that, plus additional information.
Sometimes years or decades. See the replicability crisis in psychology that’s decades in the making, and the Schron scandal that wasted years of some researchers time, just for the first two examples off the top of my head.
I don’t know if I agree that those things have anything to do with people tolerating probability and using calibration to continue working under conditions of high uncertainty.
The issue is not replication, but that results get built on; when that result gets overturned, a whole bunch of scaffolding collapses.
I think you’re also saying that when you predict that people are limited or stunted in some capacity, that we have to intervene to limit them or stunt them even more, because there is some danger in letting them operate in their original capacity.
It’s like, “Well they could be useful, if they believed what I wanted them to. But they don’t, and so, it’s better to prevent them from working at all.”
Remember, the “exception throwing” behavior involves taking the entire space of outcomes and splitting it into two things: “Normal” and “Error.” If we say this is what we ought to do in the general case, that’s basically saying this binary property is inherent in the structure of the universe.
I think it works in the specific context of programming because for a lot of functions (in the functional context for simplicity), behaviours are essentially bimodal distributions. They are rather well behaved for some inputs, and completely misbehaving (according to specification) for others. In the former category you still don’t have perfect performance; you could have quantisation/floating-point errors, for example, but it’s a tightly clustered region of performing mostly to-spec. In the second, the results would almost never be just a little wrong; instead, you’d often just get unspecified behaviour or results that aren’t even correlated to the correct one. Behaviours in between are quite rare.
I think you’re also saying that when you predict that people are limited or stunted in some capacity, that we have to intervene to limit them or stunt them even more, because there is some danger in letting them operate in their original capacity.
It’s like, “Well they could be useful, if they believed what I wanted them to. But they don’t, and so, it’s better to prevent them from working at all.”
If you were right, we’d all be hand-optimising assembly for perfect high performance in HPC. Ultimately, many people do minimal work to accomplish our task, sometimes to the detriment of the task at hand. I believe that I’m not alone in this thinking, and you’d need quite a lot of evidence to convince others. Look at the development of languages over the years, with newer languages (Rust, Julia, as examples) doing their best to leave less room for user errors and poor practices that impact both performance and security.
I think your view involves a bit of catastrophizing, or relying on broadly pessimistic predictions about the performance of others.
Remember, the “exception throwing” behavior involves taking the entire space of outcomes and splitting it into two things: “Normal” and “Error.” If we say this is what we ought to do in the general case, that’s basically saying this binary property is inherent in the structure of the universe.
But we know that there’s no phenomenon that can be said to actually be an “error” in some absolute, metaphysical sense. This is an arbitrary decision that we make: We choose to abort the process and destroy work in progress when the range of observations falls outside of a single threshold.
This only makes sense if we also believe that sending the possibly malformed output to the next stage in the work creates a snowball effect or an out-of-control process.
There are probably environments where that is the case. But I don’t think that it is the default case nor is it one that we’d want to engineer into our environment if we have any choice over that—which I believe we do.
If the entire pipeline is made of checkpoints where exceptions can be thrown, then if I remove an earlier checkpoint, then it could mean that more time is wasted if it is destined to be thrown at a later time. But like I mentioned in the post, I usually think this is better, because I get more data about what the malformed input/output does to later steps in the process. Also, of course, if I remove all of the checkpoints, then it’s no longer going to be wasted work.
Mapping states to a binary range is a projection which loses information. If I instead tell you, “This is what I know, this is how much I know it,” that seems better because it carries enough to still give you the projection if you wanted that, plus additional information.
I don’t know if I agree that those things have anything to do with people tolerating probability and using calibration to continue working under conditions of high uncertainty.
I think you’re also saying that when you predict that people are limited or stunted in some capacity, that we have to intervene to limit them or stunt them even more, because there is some danger in letting them operate in their original capacity.
It’s like, “Well they could be useful, if they believed what I wanted them to. But they don’t, and so, it’s better to prevent them from working at all.”
I think it works in the specific context of programming because for a lot of functions (in the functional context for simplicity), behaviours are essentially bimodal distributions. They are rather well behaved for some inputs, and completely misbehaving (according to specification) for others. In the former category you still don’t have perfect performance; you could have quantisation/floating-point errors, for example, but it’s a tightly clustered region of performing mostly to-spec. In the second, the results would almost never be just a little wrong; instead, you’d often just get unspecified behaviour or results that aren’t even correlated to the correct one. Behaviours in between are quite rare.
If you were right, we’d all be hand-optimising assembly for perfect high performance in HPC. Ultimately, many people do minimal work to accomplish our task, sometimes to the detriment of the task at hand. I believe that I’m not alone in this thinking, and you’d need quite a lot of evidence to convince others. Look at the development of languages over the years, with newer languages (Rust, Julia, as examples) doing their best to leave less room for user errors and poor practices that impact both performance and security.