3 ms·
It's so funny that you say that, because you are describing the way that I wish the world works, but I have found that in practice it rarely does. For example,
by haberman 12y ago
It's so funny that you say that, because you are describing the way that I wish the world works, but I have found that in practice it rarely does.
For example, here are a list of ways in which the C-to-JS compiler is far less than "perfect": http://kripken.github.io/emscripten-site/docs/porting/guidelines/index.html http://kripken.github.io/emscripten-site/docs/porting/guidel...
- derefr 12y agoThat's what I was really trying to get across—the difference between "imperfect" in other engineering, and "imperfect" in software. In other engineering, "imperfect" means "will randomly fail 0.00000001% of the time." In software, though, "imperfect" means "will work perfectly, 100% of the time, even after a quadrillion tests, within a well-specified subset of all possible inputs; will fail in arbitrary unknown ways outside of that subset." It's a difference to being "within tolerance"—even within tolerance of a physical system, stresses are still going on. Physical systems have a lifetime, and repair procedures, for a reason. But in software, you don't have to worry about "stress within tolerance." In fact, even if someone else builds an "imperfect" software system that accepts inputs with undefined results, you can just wrap it with an input validator, and suddenly it's a well-defined-100%-of-the-time system! (Of course, in implementation, software has to run on hardware, which is the other kind of imperfect system. But, surprisingly, you can write software to compensate even for that, with failover and quorum-agreement &c.)