Formal Verification: The Gap Between Perfect Code and Reality
I almost completely disagree with the author of this article.<p>Yes, formally verified systems still have bugs due to the TCB (the trusted computing base). But that&#x27;s because the TCB is precisely the <i>only</i> part of the system that is not formally verified! So of course it&#x27;s going to have bugs.<p>If so many crashing and correctness bugs were found in the (small) trusted part of formally-verified systems (well, in reality only 16 bugs were found in 3 entire formally verified systems, but I digress), imagine how many similar bugs there are in systems that are not formally verified at all!<p>If anything, what this article should be arguing is that operating systems, proof finding and verification tools and compilers should <i>also</i> be formally verified (and some already are), so that even bugs in these parts of the system are also eliminated.<p>The only part of the article that I agree with is that it&#x27;s not feasible to write 10x more proof code than real code.<p>But IMHO, this is why proof automation is really important to have - tools like Isabelle&#x2F;HOL, Why3 and SMT solvers like Z3 provide this (the latter of which the author mentions).<p>Coq, on the other hand, has much less automation and the result is that it&#x27;s much harder to use and results in larger proof code. Yet, it&#x27;s seemingly inexplicably much more popular - perhaps it&#x27;s the catchy name?