Correctness is always relative to a <i>specification</i>. More precisely, it&#x27;s the program&#x27;s specification, which must exist prior to the program itself, which defines what it constitutes for the program to be correct. So a program that “validates itself” simply doesn&#x27;t make sense.<p>Also, it seems you misunderstand Gödel&#x2F;Turing&#x2F;etc.&#x27;s result. What a consistent and sufficiently powerful formal system can&#x27;t do is prove its own <i>consistency</i> as a theorem. Obviously, it isn&#x27;t sustainable to spend all our time inventing ever more powerful formal systems just to prove the preceding ones consistent. At some point you need to assume something. This is precisely the rôle of the foundations of mathematics (or perhaps I should say <i>a</i> foundation, because there exist many competing ones): to provide a system whose consistency need not be questioned, and on top of which the rest of mathematics can be built.<p>In any case, we have gone too far away from original point, which is that, if arbitrary programs are too unwieldy to be analyzed, the only way we can <i>hope</i> to ever understand our programs is to limit the class of programs we can write. And this is precisely what (sound) type systems, as well as other program analyses, do. Undoubtedly, some dynamically safe programs will be excluded, e.g., most type systems will reject `if 2 + 2 == 4 then &quot;hello&quot; else 5` as an expression of type `String`. But, in exchange, accepted programs are free <i>by construction</i> of any misbehaviors the type system&#x27;s type safety theorem rules out. The real question is: how do we design type systems that have <i>useful</i> type safety theorems...?