3 ms·

I am surprised anyone still wants to use print debugging. Certainly it's required sometimes, and sometimes it's the quickest easiest option. I use a mix. But th

by ehnto 6y ago

I am surprised anyone still wants to use print debugging. Certainly it's required sometimes, and sometimes it's the quickest easiest option. I use a mix. But the level of insight a good debugger gives you at a glance is not possible to achieve with print debugging, and I hate when I don't have access to a debugger, it's so cumbersome. Inside significantly complex programs, plopping a breakpoint and then climbing the recorded stack frames gives you a snapshot of the program at all calls all the way up the stack. It lets me find information in a matter of moments instead of minutes. You can run commands right there in the current moment of the program you paused on, and you can even change values to what you think they should be and let it run to make sure your assumption is correct and your fix will actually work. Instead of running the program ten times in a row to debug, I do all that in one go, and I can let my curiosity run wild as I poke and prod the program as I see fit. For programs that take a while to run during development, it's not even feasible to print debug. If you're waiting 1-5 minutes to run the program, and it takes you 5 goes, you've blown nearly half an hour twiddling your thumbs. Quite frankly if you were on my team and not using decent debuggers to troubleshoot, I'd have a chat. You and I are both on the clock, use your tools and get it done! Caveat: Some debuggers suck, and print debugging is less painful, but still painful.

theamk 6y ago
Do you ever have to deal with concurrency or external services? Trying to debug a program which is making an RPC call will likely cause the remote service to timeout and fail by the time you resume program, ruining your experience. And there is also classical logic/algorithms problems: your program did not crash, but after 50 iterations of the main loop, the result set is empty. With prints, you get it all on screen and stare at the intermediate progress for a few minutes. With debugger, you can set a breakpoint... and then you have to hit "continue" 50 times, trying to remember what the values were 20 steps ago.
- ehnto 6y ago
  You do have to work around concurrency sometimes, it will obviously depend entirely on your stack but for me there is usually way to still get a debugger on the thread I want. For your second point, logic/algorithmic problems are when the debugger shines the most. If you don't know where the problem is, you can put a breakpoint somewhere you know is after the problem then climb back up the recorded stack frames to find the issue. If the issue is in a loop, you can put in a conditional watcher to only break when your condition is met, or just set a breakpoint one line after the loop and inspect the loop result right there. The most useful part of debugging is the ability to rapidly excercise your "aha" moments. When you print debug, you see the issue and go "Aha!" now you have to go verify with another print. If I see the issue in a debugger, I go "Aha!" and then immediately get to look at the variable or variables I've discovered is part of the problem. I want to make sure it's clear that I don't think print debugging is useless, it's got it's moments of usefulness. I just don't understand how someone would not want to take advantage of an advanced debugger when it's available. They are so powerful, it would be like watching a mechanic use a pair of pliers when they have access to an impact gun.
- db48x 6y ago
  You really should try Pernosco. You can record your program, and replay it as often as you like without ever having to contact the RPC service again; it replays the same response from the server in exactly the same way as it was recorded. The server never times out while you’re paused, because RR remembers the exact pattern of syscalls that your program executed, and always replays them deterministically. The server won’t time out in the play back because it didn’t time out in the recording. It really is a superpower. And instead of putting a breakpoint and then hitting continue 50 times, you query the Pernosco database for all executions of that line, and it shows them to you as a list. You can then have it evaluate expressions at those points in time, and it shows them in the same list. It’s fast too; it can evaluate your expression at hundreds of points in time faster than you can type them in.
tantalor 6y ago
You hit the nail on the head. > when I don't have access to a debugger Why can't we get rid of print debugging? Because we don't always have access to a debugger.
tgv 6y ago
I can give you a pretty useful scenario: tracing a sequence (calls, assignments, whatever). Adding a print statement at critical points will allow you to see what happened and in what order (and possibly the time intervals as well). You can copy and paste that in a document, collect other cases, and think a bit about it offline. If you would do that inside a debugger, you'd have to make a note when you hit a break point. That's not helpful. It gets worse when you can't really halt the program because there's some kind of real-time effect in your problem. Yes, you can tell debuggers to print messages instead of halting, but that's just like adding a print statement. IMO, it's even better, because when you make a change, your print statement will still be at the correct point, while your breakpoint might have shifted a line or two...
- ehnto 6y ago
  I think you might underestimate an advanced debugger. In the one I most commonly use I can collate data from different frames with watchers. I haven't personally used it, but I think the debugger in the suggested article even keeps a queryable database of data for every recorded execution. I hear you and others though, I wasn't personally suggesting print debugging should go away, I still use it here and there.
marto1 6y ago
A debugger is something that has to be developed. Printing is for the most case already there. It's not always the case if you like the one or the other. With out of the ordinary issues or places where you can't afford to sacrifice performance but still would like to have some insight printing usually wins by a large margin.
- ehnto 6y ago
  Right, but that's a choice someone has made. You or someone has decided "I am going to build or use tools that can't be debugged". We should be at a point of maturity in software tooling where that never happens, at least for commercial software companies. I don't much mind what anyone uses in the free time or on their solo SaaS, but as service providers we should be aiming to use mature and effective tooling. I'm not sure what you mean about performance, since debugging is something you should be doing once off in a local development environment, it shouldn't impact performance for users. Even videogame engines can be debugged. If you've got an issue only happening in production, you should probably try and replicate the production environment so you can debug it locally instead of messing about in prod.
jcelerier 6y ago
> For programs that take a while to run during development, it's not even feasible to print debug. If you're waiting 1-5 minutes to run the program, and it takes you 5 goes, you've blown nearly half an hour twiddling your thumbs. For me it's the opposite, a build-compile-run cycle takes 10 seconds, but loading symbols in gdb... I generally can go and make me a coffee, even with gdb index

by ehnto 6y ago

theamk 6y ago

Do you ever have to deal with concurrency or external services? Trying to debug a program which is making an RPC call will likely cause the remote service to timeout and fail by the time you resume program, ruining your experience. And there is also classical logic/algorithms problems: your program did not crash, but after 50 iterations of the main loop, the result set is empty. With prints, you get it all on screen and stare at the intermediate progress for a few minutes. With debugger, you can set a breakpoint... and then you have to hit "continue" 50 times, trying to remember what the values were 20 steps ago.

ehnto 6y ago
You do have to work around concurrency sometimes, it will obviously depend entirely on your stack but for me there is usually way to still get a debugger on the thread I want. For your second point, logic/algorithmic problems are when the debugger shines the most. If you don't know where the problem is, you can put a breakpoint somewhere you know is after the problem then climb back up the recorded stack frames to find the issue. If the issue is in a loop, you can put in a conditional watcher to only break when your condition is met, or just set a breakpoint one line after the loop and inspect the loop result right there. The most useful part of debugging is the ability to rapidly excercise your "aha" moments. When you print debug, you see the issue and go "Aha!" now you have to go verify with another print. If I see the issue in a debugger, I go "Aha!" and then immediately get to look at the variable or variables I've discovered is part of the problem. I want to make sure it's clear that I don't think print debugging is useless, it's got it's moments of usefulness. I just don't understand how someone would not want to take advantage of an advanced debugger when it's available. They are so powerful, it would be like watching a mechanic use a pair of pliers when they have access to an impact gun.
db48x 6y ago
You really should try Pernosco. You can record your program, and replay it as often as you like without ever having to contact the RPC service again; it replays the same response from the server in exactly the same way as it was recorded. The server never times out while you’re paused, because RR remembers the exact pattern of syscalls that your program executed, and always replays them deterministically. The server won’t time out in the play back because it didn’t time out in the recording. It really is a superpower. And instead of putting a breakpoint and then hitting continue 50 times, you query the Pernosco database for all executions of that line, and it shows them to you as a list. You can then have it evaluate expressions at those points in time, and it shows them in the same list. It’s fast too; it can evaluate your expression at hundreds of points in time faster than you can type them in.

tantalor 6y ago

You hit the nail on the head. > when I don't have access to a debugger Why can't we get rid of print debugging? Because we don't always have access to a debugger.

tgv 6y ago

I can give you a pretty useful scenario: tracing a sequence (calls, assignments, whatever). Adding a print statement at critical points will allow you to see what happened and in what order (and possibly the time intervals as well). You can copy and paste that in a document, collect other cases, and think a bit about it offline. If you would do that inside a debugger, you'd have to make a note when you hit a break point. That's not helpful. It gets worse when you can't really halt the program because there's some kind of real-time effect in your problem. Yes, you can tell debuggers to print messages instead of halting, but that's just like adding a print statement. IMO, it's even better, because when you make a change, your print statement will still be at the correct point, while your breakpoint might have shifted a line or two...

ehnto 6y ago
I think you might underestimate an advanced debugger. In the one I most commonly use I can collate data from different frames with watchers. I haven't personally used it, but I think the debugger in the suggested article even keeps a queryable database of data for every recorded execution. I hear you and others though, I wasn't personally suggesting print debugging should go away, I still use it here and there.

marto1 6y ago

A debugger is something that has to be developed. Printing is for the most case already there. It's not always the case if you like the one or the other. With out of the ordinary issues or places where you can't afford to sacrifice performance but still would like to have some insight printing usually wins by a large margin.

ehnto 6y ago
Right, but that's a choice someone has made. You or someone has decided "I am going to build or use tools that can't be debugged". We should be at a point of maturity in software tooling where that never happens, at least for commercial software companies. I don't much mind what anyone uses in the free time or on their solo SaaS, but as service providers we should be aiming to use mature and effective tooling. I'm not sure what you mean about performance, since debugging is something you should be doing once off in a local development environment, it shouldn't impact performance for users. Even videogame engines can be debugged. If you've got an issue only happening in production, you should probably try and replicate the production environment so you can debug it locally instead of messing about in prod.

jcelerier 6y ago

> For programs that take a while to run during development, it's not even feasible to print debug. If you're waiting 1-5 minutes to run the program, and it takes you 5 goes, you've blown nearly half an hour twiddling your thumbs. For me it's the opposite, a build-compile-run cycle takes 10 seconds, but loading symbols in gdb... I generally can go and make me a coffee, even with gdb index