I never used a debugger that can run a program backwards but I would like to. Now I wonder if there is much evidence and theory about backwards runnable programming, when and why a program can be run backwards or when and why not?Intuitively I find that the computer should be able to run the program backwards, if it once has run the program forward knowing that the program will run backwards hence saving states of the program that otherwise might get lost and deallocated. Debugging is just a practical example. I'm also interested in it for the sake of the theory of reversibility, if the program can be run backwards, then what the program does is reversible, isn't it?
Running programs backwards
automata;programming languages
In theory, to actually run program backwards would require you to undo any effects of program execution. Doing that should be relatively simple, if inefficient, for memory changes, harder for changes on disk and impossible for networking. And if the code depends on any external state (time of day, file on disk that could be modified by another process), rewinding and running it again won't produce the same result.In practice, what is possible is to allow you to look at the state of the program at some point in its execution, but without allowing you to restart from that point. This way, there are no problems with external state, because this form of rewinding doesn't need to undo any state changes (except for memory) and stepping forwards will always produce the same result (because the code is not actually executed again). This form of rewinding is implemented in Visual Studio, under the name Historical Debugging, though it doesn't record program state at every instruction or line of code, only at every method call.