But I disagree with the other opinion expressed in the original post. The wonderful thing about the halting problem is that although it is a deep result that reveals something very interesting and fundamental about general purpose computation, it *isn’t* very difficult to understand. The argument is surprisingly simple.

(Also: there was one part of the “coping strategies” section at the end of the talk that I think is misleading. Tom implies that if you want to know whether some interesting property holds for a program you have written, you have to live with inexaustive tests, or some other kind of approximation to certainty: that you can’t ever prove it for sure. Not so. For a particular interesting true property of a particular program you wrote, it probably *is* possible to model that property and prove it formally for that program. The reasons for not doing so are pragmatic ones – it’s usually much more trouble than it is worth, and you may be as likely to make a mistake in the modelling or formalization of the proof as you are in writing the program.)

]]>this–together with successful ‘coping stragtegies’–is definitely something that each programmer should understand. i found the talk extremely helpful and instructive.

]]>Not exactly. It’s very possible to know what SOME programs do with all possible inputs. Think of a program that always prints “42” and stops, for example.

The Halting Problem proves that’s it’s impossible to have an algorithm that can be given ANY program and ANY input and say what that arbitrary program would do.

]]>