3 ms·

I'm a little confused about their apparent implication that they have to single step all the way to the point that they want to inspect. Maybe older debuggers

by Tcepsa 8y ago

I'm a little confused about their apparent implication that they have to single step all the way to the point that they want to inspect. Maybe older debuggers made you do this? But today, breakpoints are useful and seem to be widely supported, so you can run the program at full speed to the point of inspection, and then instead of getting a drive-by snap-shot as you do with a printout, you can do a more in-depth interrogation of the state of the system "Oh, this part of the state has value X as I expected, maybe it's this other part of the state instead--yes, there is something weird over here!" instead of discovering value X in the first run, adjusting your print statement, recompiling, and discovering the unexpected behavior. All that having been said, surely there is still great value in applying a similar amount of consideration as to where to put the breakpoints as you would in determining where to put a print statement! (edit: and also in thinking hard about what new values to inspect if your initial guess is not borne out)

dmitryminkovsky 8y ago
> "Oh, this part of the state has value X as I expected, maybe it's this other part of the state instead--yes, there is something weird over here!" instead of discovering value X in the first run, adjusting your print statement, recompiling, and discovering the unexpected behavior. This is why I love debuggers. Well, the Chrome debugger. But I find that this situation is less common or doesn't happen at all when I'm writing Java with unit tests. It seems like dynamic environments like the browser are more ripe for debugger use as you describe. But then again, I've met some incredible developers who made really great browser UI (ie the RethinkDB UI) who told me they've never used the browser debugger.
XorNot 8y ago
The real trick is that gdb is scriptable. You don't print debug - you set your breakpoints, add some logic for deciding what you want to output and where, and then run at full speed.
deleted 8y ago
[deleted]
nitrogen 8y ago
I've never found something as nice as Ruby's binding.pry. I've added JRuby to Java projects temporarily just to get the interactive introspection of a REPL.

by Tcepsa 8y ago

dmitryminkovsky 8y ago

> "Oh, this part of the state has value X as I expected, maybe it's this other part of the state instead--yes, there is something weird over here!" instead of discovering value X in the first run, adjusting your print statement, recompiling, and discovering the unexpected behavior. This is why I love debuggers. Well, the Chrome debugger. But I find that this situation is less common or doesn't happen at all when I'm writing Java with unit tests. It seems like dynamic environments like the browser are more ripe for debugger use as you describe. But then again, I've met some incredible developers who made really great browser UI (ie the RethinkDB UI) who told me they've never used the browser debugger.

XorNot 8y ago

The real trick is that gdb is scriptable. You don't print debug - you set your breakpoints, add some logic for deciding what you want to output and where, and then run at full speed.

deleted 8y ago

[deleted]

nitrogen 8y ago

I've never found something as nice as Ruby's binding.pry. I've added JRuby to Java projects temporarily just to get the interactive introspection of a REPL.