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-printi

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.