4 ms·

The idea of traveling forward and back in time in a debugger has been around for a long time, even before the era of modern programming the idea was explored an

by todd8 9y ago

The idea of traveling forward and back in time in a debugger has been around for a long time, even before the era of modern programming the idea was explored and implemented. I recall conversations with people working on this in the 1970's, but I never saw one working in action. I've never had much use for debuggers. Of course I've had bugs that could have been found faster with debuggers, but I usually find myself using logs of the information I want to be quicker to work with. Of course this depends upon the program and the environment one is debugging in. I'd rather reason about the program statically than try to follow it dynamically in a debugger. On the other hand, one of the best kernel programmers I ever worked with carried his own debugger around and would implement it in a new kernel he was working on just so he could have it at hand. (That's you Dammon if you're out there!) [1969] Rand's Extendable Debugging and Monitoring System, https://www.rand.org/content/dam/rand/pubs/research_memoranda/2009/RM5772.pdf https://www.rand.org/content/dam/rand/pubs/research_memorand... [1988] Feldman, S.I. and Brown, C.B. (1988). Igor: A system for program debugging via reversible execution. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.85 http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.85. 2238&rep=rep1&type=pdf

roca 9y ago
The idea has been around a long time. Making it practical has been a much more recent development. Ideas are cheap. If you're using logs, you're using a debugger, just a very limited one. Reasoning about a program statically is great, but once it gets above a certain size you can't keep it all in your head and you must collect data to narrow down the problem. That's where a debugger comes in. Then there are the cases where you're debugging someone else's code and you don't have it in your head in the first place.
- roca 9y ago
  Oh yeah, and then there are the times when you reason about the program in your head and your reasoning is wrong. That happens a lot. Sometimes it's because of false but reasonable assumptions like "the compiler compiled my code correctly" or "the CPU executed my program correctly".

by todd8 9y ago

roca 9y ago

The idea has been around a long time. Making it practical has been a much more recent development. Ideas are cheap. If you're using logs, you're using a debugger, just a very limited one. Reasoning about a program statically is great, but once it gets above a certain size you can't keep it all in your head and you must collect data to narrow down the problem. That's where a debugger comes in. Then there are the cases where you're debugging someone else's code and you don't have it in your head in the first place.

roca 9y ago
Oh yeah, and then there are the times when you reason about the program in your head and your reasoning is wrong. That happens a lot. Sometimes it's because of false but reasonable assumptions like "the compiler compiled my code correctly" or "the CPU executed my program correctly".