I remember when I was 18, back in 1998, installing a specially licensed copy of this thing called "Visual C++" and doing just that, i.e the thing they call 'debugging'.
As I understand his point, it's about not having to pause the program. This seems like actually a quite useful feature, and probably not that hard to implement in say, visual studio (possibly requiring a manual trigger for efficiency). So the question is, why has it not happened in 20 years. Why are debuggers at basically the same level of sophistication as 20 years ago, when there's seemingly a lot of low hanging fruit. I think he have a point, and adding to that, how come so many environments aren't even up to par with the state 20 years ago. Many people doesn't even use a prober debugger, deferring to printf debugging and at most command line GDB in exceptional cases, due to bad environment support.
With VS and .NET you can pause the program, inspect variables, change variables, execute arbitrary code using a REPL, change threads, view memory usage, edit code and continue the program (if properly configured), debug into framework libraries and even third party libraries with a bit of hackery. You used to be able to debug JS - not sure if you can still do this as I haven't tried for ages since the Chrome debugger is pretty good.
You can also use the same tools to debug a crash dump although often a lot of info is lost, but it can be useful.
Admittedly nothing much has changed in years and it would be good to see more.
One thing I would like to see is a time travelling debugger akin to what is provided with Elm, but Elm apps have state concentrated in one place so it is easier to implement there than for a .NET program probably.
Outside of .NET I am not sure of the quality of debugging tools. Jetbrains created something pretty good for Ruby which I used once, it was quite nice. But I am sure there are languages without much support and it would be frustrating to use them.
Haskell is an interesting example because you don't often need to debug, because of the purity you would more likely run additional unit tests / property-based tests on the functions to find the problem. Having said that I've only made small Haskell apps, nothing in the day job.
