But I thought it was a widely celebrated result.
But I thought it was a widely celebrated result.
And then, when I raised concerns in Zulip about Lean's metaprogramming facilities being used to trick the pipeline into accepting false proofs, he said the opposite. He even emphasized that the formalization efforts are not for checking proof correctness, but for cataloguing truths we believe in.
This kind of equivocation turned me away from that community, to be honest. That was an extremely frustrating experience.
I imagine one bias is because formal verification is such a huge effort, you're only going to do it for really interesting and impactful proofs, which means the proofs that get formal verified will already have been reviewed and critiqued a lot, and will be less likely to have glaring critical errors.
That's part of the motivation to formalise it. When a proof gets really long and complex, relies on lots of other complex proofs, and there's barely any single expert who has enough knowledge to understand all the branches of maths it covers, there's more chance there's a mistake.
There's a few examples here of errors/gaps/flaws found while formalizing proofs that were patched up:
https://mathoverflow.net/questions/291158/proofs-shown-to-be...
My understanding is it's common to find a few problems that then need to be patched or worked around. It's a little like wanting to know if a huge codebase is bug-free or not: you might find some bugs if you formalized the code, but you can probably fix the bugs during the process because it's generally correct. There can be cases where it's not fixable though.
It takes thorough review by advanced mathematicians to verify correctness.
This is not unlike a code review.
Most people vastly underestimate how complex and esoteric modern research mathematics are.
The systems we deal with in software are massive compared with your typical mathematical framework though. But FLT is probably on similar scope.