|
|
|
|
|
|
by rspeer
4279 days ago
|
|
|
Why would you be better off? I don't see any advantage in having the overly optimistic belief that there's some universal, correct set of axioms. You can still do all the math you could do before -- and if Carroll or GEB gets you more interested in the fundamentals of math, you can do even more. Yes, you have to accept some basis of mathematics, and you now understand that some true things will be unprovable in the basis you just accepted. But that doesn't stop you from proving things. I think you might have just transferred your optimism about math to code instead. How do you know your programming language is doing what you asked it to? That you asked it to do the right thing at all? That the compiled code has the correct behavior? That your hardware works as advertised and is not failing at the moment? In both code and math, you have to accept some abstractions that you're not going to worry about, but the things you do with math are certainly more verifiable. |
|
|
My "optimism" is more for my intuition; working code is experimental confirmation.
It's easier to be optimistic about code than proofs. Firstly, working code only needs to work in the specific cases you're using (that you test for); but a proof must work in every possible case. Thus, working code is simpler and easier to check, because it's aiming at less. My code almost always confirms my intuition.
Yes, it's also helpful to have the automatic, mechanical check of executable code; and as you say, this relies on compilers, OSes, silicon, hardware. (Though, anecdotally, I have noticed subtle problems that I eventually diagnosed and confirmed to be compiler and hardware bugs.) BTW, yes I have tried COQ (proof assistant; somewhat mechanical proof checking), but simple ideas become very complex to prove, and the problem of bugs in COQ itself etc is of greater concern, for the next reason:
Secondly, and relatedly, is that the standard is much lower for code. It just needs to work. Whereas a mathematical proof is supposed to be absolutely true. In other words, I don't ask as much from code. If there turns out to be a bug, it's just learning more about the problem; about the world. It's an engineering flaw. But if my proof is wrong, the game is lost.
An argument against my intuition is probably more telling. Though my faith in it has turned out to be justified many many times, I certainly can be wrong. My only real excuse is that, as a human being, I have nothing else to fall back on but my sense of reality and reason. That's my hardware; if it's wrong, I really am lost. So I might as well trust it. Fortunately, it's almost always right; probably because I try to see things from many angles and check them in many ways before my intutive sense is fully formed.