6 ms·

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 terribl

by vitd 10y ago

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.

Tloewald 10y ago
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 10y ago
  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.
T-hawk 10y ago
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 10y ago
  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?
gnaritas 10y ago
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.
- cm3 10y ago
  How do you make sure there's no corrupted state and that the data structures in memory fit the new code?
  - vvanders 10y ago
    You don't. Worst case is you had wrong assumptions and restart the program, same as if you didn't have the ability to change things. Best case thought, it's so useful. It's also incredible for editing tunables on the fly(think videogame gameplay values, layout values for UI, etc).
    - qznc 10y ago
      Worst case is you don't know you broke consistency. Then you can waste hours hunting for ghost bugs that only occur because of the hot-code-reload.
      - tedks 10y ago
        As someone who worked on dynamic updating research projects for years I can attest to the really shitty bugs dynamic updating can cause.
    - infinite8s 10y ago
      Editing tunables is possible without recompiling new code. It's just setting the variables to new values.
      - vvanders 10y ago
        Not if you want to change the formula the the tunable uses.
stcredzero 10y ago
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 10y ago
  I loved developing in eclipse with hot code reload. 0-second changes + debugging all in one.
  - stcredzero 10y ago
    Eclipse basically started out as a port of the VisualAge for Smalltalk environment to Java.
    - grandinj 10y ago
      That port was horrible. It was only when they dumped the smalltalk codebase and started again that it became useful.
      - stcredzero 10y ago
        Pretty much par for the course for those days. Converting Smalltalk apps to Java ones usually yielded horrble Java apps, because Java was very immature, to be frank. While it was still VisualAge for Java, it was considered one of the best Java IDEs of the time.
make3 10y ago
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
snarfy 10y ago
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.

by vitd 10y ago

Tloewald 10y ago

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 10y ago
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.

T-hawk 10y ago

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 10y ago
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?

gnaritas 10y ago

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.

cm3 10y ago
How do you make sure there's no corrupted state and that the data structures in memory fit the new code?
- vvanders 10y ago
  You don't. Worst case is you had wrong assumptions and restart the program, same as if you didn't have the ability to change things. Best case thought, it's so useful. It's also incredible for editing tunables on the fly(think videogame gameplay values, layout values for UI, etc).
  - qznc 10y ago
    Worst case is you don't know you broke consistency. Then you can waste hours hunting for ghost bugs that only occur because of the hot-code-reload.
    - tedks 10y ago
      As someone who worked on dynamic updating research projects for years I can attest to the really shitty bugs dynamic updating can cause.
  - infinite8s 10y ago
    Editing tunables is possible without recompiling new code. It's just setting the variables to new values.
    - vvanders 10y ago
      Not if you want to change the formula the the tunable uses.

stcredzero 10y ago

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 10y ago
I loved developing in eclipse with hot code reload. 0-second changes + debugging all in one.
- stcredzero 10y ago
  Eclipse basically started out as a port of the VisualAge for Smalltalk environment to Java.
  - grandinj 10y ago
    That port was horrible. It was only when they dumped the smalltalk codebase and started again that it became useful.
    - stcredzero 10y ago
      Pretty much par for the course for those days. Converting Smalltalk apps to Java ones usually yielded horrble Java apps, because Java was very immature, to be frank. While it was still VisualAge for Java, it was considered one of the best Java IDEs of the time.

make3 10y ago

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

snarfy 10y ago

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.