&gt; The system you outline works perfectly as long as you limit yourself to provable assertions.<p>Of course. And if a formal system doesn&#x27;t let you prove the theorems you want, you would just switch formal systems.<p>&gt; But Gödel&#x27;s theorems have led to examples of unprovable assertions, thus moving beyond the hypothetical into a realm that might collide with future algorithms likely to be much more complex than typical modern algorithms, including some that may mistakenly be believed to be proven correct.<p>Programming is applied logic, not religion. And a proof doesn&#x27;t need to be “believed”, it just has to abide by the rules of a formal system. In some formal systems, like intensional type theory, verifying this is a matter of performing a syntactic check.<p>&gt; If we&#x27;re balancing a bank&#x27;s accounts, I think we&#x27;re safe.<p>I wouldn&#x27;t be so sure.<p>&gt; In the future, when we start modeling the human brain&#x27;s activities in code, this topic will likely seem less trivial,<p>I see this as more of a problem for specification writers than programmers. Since I don&#x27;t find myself writing specifications so often, this is basically Not My Problem (tm). Even if I wrote specifications for a living, I&#x27;m not dishonest or delusional enough to charge clients for doing something I actually can&#x27;t do, like specifying a program that claims to be an accurate model of the human brain.<p>&gt; and the task of avoiding &quot;arbitrary programs,&quot; and undecidable assertions (or even recognizing them in all cases), won&#x27;t seem so easy.<p>I don&#x27;t see what&#x27;s so hard about sticking to program structures (e.g., structural recursion) for which convenient proof principles exist (e.g., structural induction).<p>Please, get yourself a little bit of mathematical education before posting your next reply. You&#x27;re so stubbornly wrong it&#x27;s painful to see.