>Neither of those limits actually makes solving the problem feasible in practice.

That's the point. Theoretical limitations has no bearing on solving the practical problem. That is why RichardHeart's original point [1] is wrong.

[1] The halting problem states you can't predict what a turing complete program will do, until you run it. This means to some degree, that you can't predict what your "smart" contract will do, until it does it. Thus turing completeness causes security to be far, far harder than non turing completeness. This is how you lose the millions of dollars as the DAO did after it passed audits.

Pretty sure the parent was saying the opposite. Testing every possible input is infeasible, since the number of possible inputs (and number of possible states) is HUGE.

That is not the opposite of what I said. That is a reason why what I said is true.

Parent said "Neither of those limits actually makes solving the problem feasible in practice." This is correct, since the input space is too huge to feasibly explore. Yes, it is technically correct that there are a finite number of states that your laptop can be in. No, it does not mean that I can practically enumerate all possible states my code can be in.

Formal verification will be necessary in practice. This is not an ideal outcome either, since (1) you have to formally specify the problem you're trying to solve and (2) the proof that the code meets the specification can easily be bigger than the program, by many orders of magnitude. Even this does not guarantee that bugs won't happen, since there's no guarantee that your specification accurately describes the problem you're solving.