[vitd]

When you say "alter code and re-compile on the fly," do you mean and continue debugging without stopping the app and re-running? Because if so, that's a terrible way to debug. You now have state that may not be possible to achieve with the new binary you've made, and you may be debugging something that won't every exist in reality. And it may be very hard to tell that's the case. That doesn't sound very useful. It sounds very dangerous.

[T-hawk]

I find that's exactly where the debugger is most useful. I know I'm trying to reach or examine a state that my binary can't achieve. That's the problem. The debugger lets me poke around to figure out what exactly is wrong with my state, faster and more immersive than recompiling and rerunning every time. Then I fix the binary to match.

It occurs to me now that's essentially using the debugger as a REPL, but with access to a whole runtime's worth of external state. That's not a bad tool to have in your box.

[btown]

And to be sure, this is exactly why Jupyter is so powerful for experimentation, especially when doing data science. When you can run lines independently, alter them and re-run them, but keeping all the state of the previous lines, it's so much better than needing to re-run from the beginning. Of course, you can shoot yourself in the foot if some of those lines are like (i = i + 1) and you end up incrementing i by (# times you've run the code) rather than (# times it appears in the code). But if you name your variables sanely and treat them as const, you can easily avoid this.

The question at the core here is: is a debugger meant for experimentation to find the (often subtle) root cause of a defect, or is it meant to be a read-only window onto state during execution?

[stcredzero]

Because if so, that's a terrible way to debug.

If you're in a codebase composed largely of side-effect free functions or well encapsulated Object Oriented code, it's a very good way to debug. I had great success with such debugging and even coding and new development in Smalltalk environments for over a decade.

On the other hand, if your codebase is full of side effects and doesn't have good encapsulation (perhaps there's a lot of fiddling with globals) then you're going to have a bad time. But to me this isn't because the debugging method is bad. To me, it's because your codebase is designed with lots of tight coupling and side effects. You have an architecture that makes it harder to reason, debug, and refactor your code. This isn't just spouting. I'm basing this on many years of experience. And yes, I saw both kinds of Smalltalk code, and the effect is exactly as I described. Guess which codebases were more productive?

[jbverschoor]

I loved developing in eclipse with hot code reload. 0-second changes + debugging all in one.

[vitd]

Well, I have to use OpenGL for my development, and it's a giant state machine that works mainly via side-effects. It's notoriously frustrating to work with, but that's life. I realize not all code works that way, but I'd bet the majority of code does. So I stand by my statement that it's a terrible way to debug, maybe with the caveat "unless you can work with only pure code and no state."

[Tloewald]

I believe Visual Studio does this by simply rewinding to the function entry point which addresses most of the concerns you've raised. A debugger is just an aid to reasoning about your code, not a substitute for it.

You might make the same argument against unit tests, or little hacks you write to separate out a problematic piece of code from an even more complicated context.

[nitrogen]

I believe Visual Studio does this by simply rewinding to the function entry point which addresses most of the concerns you've raised.

Live recompilation in Java (at least in Eclipse) behaves basically the same way.

[gnaritas]

If you've never written code in a live debugger session, moved the execution point back up, and immediately run over the code you just wrote, you have a crappy debugger. VB6 could do this, Smalltalk does this, it's not dangerous, it's damn productive.

[rbobby]

VB6... got so much hate but folks just don't seem to see how useful it's debug mode was.

Oh sure... VB6 and good OO design and modern practices (unit tests, dependency injection, etc) don't mix. But... if you need to sit down and "hack out" a bunch of working code quickly it was pretty hard to beat.

Python with the VB6 ide/debugger experience would likely take the scientific computing field by storm.

I miss it... especially since I've never been able to get "edit & continue" to work at all in Visual Studio.

[MichaelGG]

VS does this and I've used .NET since its start. It's useful now and then, but a REPL is far more useful. Considering the cost of Edit-and-Continue I'm not sure it's worth it. I'd have much prefer MS to have spent the effort on improving language tech or working on REPLs.

[cm3]

How do you make sure there's no corrupted state and that the data structures in memory fit the new code?

[snarfy]

It's not dangerous. It's awesome.

There is all of this excitement around ideas like Light Table, allowing you to see the output of your code inline as you develop it. Being able to alter code and recompile on the fly in the debugger gives you a very similar experience.

[make3]

there are some situations where execution of the rest of the program up to that point takes forever, and you don't want to have to spend however many hours/days/weeks reexecuting just for a typo. scientific computing comes to mind, with its huge simulations