[roca]

I wonder if the author has actually used a debugger with practical reverse execution, like rr, UndoDB or TTD. It is not just another feature like "pretty-printing STL data structures"; it changes everything. Debugging is about tracing effects back to causes, so reverse execution is what you want and traditional debugging strategies are workarounds for not having it.

Those record-and-replay debuggers also fix some of the other big problems with debugging, such as the need to stop a program in order to inspect its state.

The author is right that the traditional debugger feature set leaves a lot to be desired. Where they (and many other developers) go wrong is to assume that feature set (wrapped in a pretty Visual Studio interface) is the pinnacle of what debuggers can be. It's an understandable mistake, since progress in debugging has been so slow, but state-of-the-art record-and-replay debuggers prove them wrong. Furthermore, record-and-replay isn't the pinnacle either; much greater improvements are possible and are coming soon.

[wallnuss]

I especially use rr as an exploration tool. It allows me to ask not the question "Where does the program go from here", but rather "Where did it come from".

I couldn't do my daily work without rr, since often I work with systems that are large and complex and I didn't write myself.