4 ms·

While I sometimes use one debug tool or another, I have never understood the aversion to print statements reflected in the title. Sometimes, often even, a prin

While I sometimes use one debug tool or another, I have never understood the aversion to print statements reflected in the title. Sometimes, often even, a print statement is just fine, and anything else is overabstracting it. Not saying other options aren't nice to have available, just that there is nothing wrong with using a simple print statement in many situations.

craftyguy 8y ago
Once you go down the path, it's easy to start adding more and more, and it's easy to forget about them. They sometimes blend in well with patches you generate, since it's just a 'print()' and nothing obvious like 'import pdb; pdb.set_trace()'
- _jal 8y ago
  That's a matter of being organized and competent, not a fault of print(). People create bugs by forgetting things all the time. If you believe their spin, FB snarfed millions of contact lists by accident because of that. I've troubleshot countless things that happened because of code that fell between the cracks. And on the other side of that, I could tell you about the time we went a month without logs in production because someone didn't properly test a library change, so everyone's carefully manicured logging broke. There's nothing wrong with print(), at least that isn't wrong with a lot of other things.
  - oblio 8y ago
    > That's a matter of being organized and competent, not a fault of print(). Or you can be organized and competent at a higher level and just use tools. We're using computers for a reason :)
- maw 8y ago
  When the language I'm using permits it -- that is, when I'm not using Python -- I deliberately misindent them. They're very visible in diffs then. And even if accidentally committed they're still easy to spot and eliminate later.
  - Gibbon1 8y ago
    Classic in C is to use a define to enable/disable print statements. //#DEBUG 1 #include "debug.h"
  - craftyguy 8y ago
    That's nice and all, but we're kind of talking about Python here, which won't allow misindentation.
Gibbon1 8y ago
Because the observability you get with a print statement is limited. You can't do further investigation without modifying the code and running it again. With a debugger you can explore the program state interactively. My experience with python is limited but in my day job it's not uncommon to be tracking down stuff that happens infrequently. Debug cycles get brutally long.
- deleted 8y ago
  [deleted]
- kurtisc 8y ago
  You also can't be confident that a debugged program is in a natural state without restarting it, at which point the re-setting of the breakpoints and scripting you did in the last invocation - or saving and loading what you've already done - is a pain point. If all of this is quicker than recompiling/relaunching, then IMO there is a second bug in a lack of effective logging. Most bugs I create are for simple reasons and can be found by scanning the first error logs. If I add print statement debugging because I couldn't then they'll often be adapted into additional logging. If I use a debugger for this as my first tool and don't add logs, I'll have to do it again next time, too[1]. If the bug is not a simple one and is not a structural bug, there's a decent chance it's something debuggers deal with poorly: data races, program boundaries, non-determinism, memory errors. If it's something that can be found by calling a function with certain parameters, it's a missing test case. So the times I find debuggers to be worth it are after I've already decided it's a difficult yet uncommon bug. So I use them with despair. [1] If I fix it with a debugger and then add the logs, I still have to prove it gives the right output when it fails.
kurtisc 8y ago
I agree. Print is the most fundamental tool available to you: debuggers are kernel and hardware spanning monsters that introduce an external logic dependency. We don't advocate for more complexity than is necessary in other places.
- rossdavidh 8y ago
  "Simple is better than complex". The simplest tool that gets the job done, is the right one to choose for that situation.

craftyguy 8y ago

Once you go down the path, it's easy to start adding more and more, and it's easy to forget about them. They sometimes blend in well with patches you generate, since it's just a 'print()' and nothing obvious like 'import pdb; pdb.set_trace()'

_jal 8y ago
That's a matter of being organized and competent, not a fault of print(). People create bugs by forgetting things all the time. If you believe their spin, FB snarfed millions of contact lists by accident because of that. I've troubleshot countless things that happened because of code that fell between the cracks. And on the other side of that, I could tell you about the time we went a month without logs in production because someone didn't properly test a library change, so everyone's carefully manicured logging broke. There's nothing wrong with print(), at least that isn't wrong with a lot of other things.
- oblio 8y ago
  > That's a matter of being organized and competent, not a fault of print(). Or you can be organized and competent at a higher level and just use tools. We're using computers for a reason :)
maw 8y ago
When the language I'm using permits it -- that is, when I'm not using Python -- I deliberately misindent them. They're very visible in diffs then. And even if accidentally committed they're still easy to spot and eliminate later.
- Gibbon1 8y ago
  Classic in C is to use a define to enable/disable print statements. //#DEBUG 1 #include "debug.h"
- craftyguy 8y ago
  That's nice and all, but we're kind of talking about Python here, which won't allow misindentation.

Gibbon1 8y ago

Because the observability you get with a print statement is limited. You can't do further investigation without modifying the code and running it again. With a debugger you can explore the program state interactively. My experience with python is limited but in my day job it's not uncommon to be tracking down stuff that happens infrequently. Debug cycles get brutally long.

deleted 8y ago
[deleted]
kurtisc 8y ago
You also can't be confident that a debugged program is in a natural state without restarting it, at which point the re-setting of the breakpoints and scripting you did in the last invocation - or saving and loading what you've already done - is a pain point. If all of this is quicker than recompiling/relaunching, then IMO there is a second bug in a lack of effective logging. Most bugs I create are for simple reasons and can be found by scanning the first error logs. If I add print statement debugging because I couldn't then they'll often be adapted into additional logging. If I use a debugger for this as my first tool and don't add logs, I'll have to do it again next time, too[1]. If the bug is not a simple one and is not a structural bug, there's a decent chance it's something debuggers deal with poorly: data races, program boundaries, non-determinism, memory errors. If it's something that can be found by calling a function with certain parameters, it's a missing test case. So the times I find debuggers to be worth it are after I've already decided it's a difficult yet uncommon bug. So I use them with despair. [1] If I fix it with a debugger and then add the logs, I still have to prove it gives the right output when it fails.

kurtisc 8y ago

I agree. Print is the most fundamental tool available to you: debuggers are kernel and hardware spanning monsters that introduce an external logic dependency. We don't advocate for more complexity than is necessary in other places.

rossdavidh 8y ago
"Simple is better than complex". The simplest tool that gets the job done, is the right one to choose for that situation.