Readit NewsThis is true in mathematical sense, but unhelpful in UX sense.
- "Null pointer dereference"
- "Out of memory"
- "Disk is full"
- "File does not exist"
- "File does not exist in cache"
- "File exists but is corrupt"
- "Access denied"
- "Connection reset by peer"
It's pretty obvious that all of the above is generally unwanted most of the time.
However, putting them all in the same bag labeled "error", and forcing them to be treated the same way might be counterproductive. Sometimes you might want to panic. Sometimes you might want to retry. Sometimes you might want to ignore!
Now, if your program isn't interactive (such as a compiler), halting on any error might be a choice. But you still have to provide contextualized and accurate error messages, which is easy for the case "File does not exist", and a lot less easy for the case "Out of range index".
What about Prolog ? How is it not a counter-example of this ?
The self-correcting mechanisms of science can only correct knowledge. Those mechanism work mainly by requiring the research works to be checkable by others. Self-correctness emerges by the accumulation of checks on the same topic, all leading to the same conclusion, and by the progressive retractation of bad research ... not by the elimination of "bad researchers".
Efficiently "correcting" people, whatever that means, is a different beast. Such a mechanism belongs to an administrative entity who can emit decisions - and, by construction, who can make errors.
Isn't this how a lot of non-math majors learn math at uni? You learn how to use it, but you don't learn the proofs behind it? When I dove into a first codebase, I took the above said approach because that's how I learned (most) math.
A younger me would've find the Tools section valuable.
Which makes sense, at least firstly, considering that understanding a proof is a lot easier when its conclusion is already familiar.
Of course, every physics engine behaves a little differently from the others, so, if you game is physics centered (pinball, racing), switching implementation might result in a slightly different game - but having the core of your game depends on the implementation details of some 3rd-party library might not be a good idea anyway.
In general, the more you sprinkle your code with dependencies to 3rd party libraries, the less control you have over the resulting product.
Your point still stands, though, for some very low-level "utility" libraries like boost or the STL, or any standard library replacement , and more generally, libraries holding "vocabulary" types.
In the good old times most video games weren't like that.
It's a pity that those times are gone, to the point video games are now used as such a comparison point!
This is why everyone remembers the MPMan F10 and no one has heard of the iPod.
Being the first to get it right is more important than being the first to get to market.
This is indeed really impressive!
(direct link: https://boricj.net/atari-jaguar-sdk/2024/01/02/part-5.html )