6 ms·

Absolutely, I don't understand why using print() or its equivalent in other languages is looked down upon. It's quick way to narrow down the "area of search" be

by 0xFFFE 6y ago

Absolutely, I don't understand why using print() or its equivalent in other languages is looked down upon. It's quick way to narrow down the "area of search" before bringing in the big guns.

yoz-y 6y ago
It definitely has its place. The problem is mostly that you have to actually change your code to debug it, and then remember to change it back.
maccard 6y ago
> It's quick way to narrow down the "area of search" before bringing in the big guns. What are the big guns? with a debugger, I can stick a breakpoint and look at the entire state of everything. Given we're talking about Python, in pycharm [0] you can even execute your print statements in the debugger if you so wish. If you get the location wrong, or want to see what's going on elsewhere you can just continue execution and use another breakpoint. This is even more important if you have a long compile/deploy cycle (I work in games, and rebuilding and deploying to a console can be a >10 minute iteration time) [0] https://www.jetbrains.com/help/pycharm/part-1-debugging-python-code.html#start-debugger-session https://www.jetbrains.com/help/pycharm/part-1-debugging-pyth...
- ZaoLahma 6y ago
  Sometimes sticking the debugger into the wheel makes stuff come flying over the handle bars in spectacular ways that have nothing to do with what you wish to observe. You might not even know which wheel to jam the debugger stick into, if the behaviour is complex. In these cases prints work well as a less intrusive way to get a rough idea of what is going on.
  - maccard 6y ago
    I don't understand your wheel analogy, sorry. > You might not even know which wheel to jam the debugger stick into, if the behaviour is complex. If you don't know where to put a breakpoint, how do you know where to put a print statement?
    - Macha 6y ago
      Imagine putting breakpoints in multiple tight loops in the stage of narrowing the search space. Imagine how many times you need to click next. A conditional breakpoint will only help if you know the condition you're looking for, but there's stage before that of "Well, what looks strange during execution". Also for multithreaded code, stopping one thread dead for long enough for a human to investigate it can inadvertently resolve all sorts of race conditions.
      - sebastialonso 6y ago
        What I imagine Macha is arguing for is that the cost of using print is extremely small, smaller at least than breakpoints. No one is saying breakpoints are useless, sometimes printing is 'cheaper' in time and effort in order to locate the region code of code in which using breakpoints is cheaper.
        Macha 6y ago
        Yes, print() and breakpoints are different tools with different uses and there's cases where one is superior to the other. This is why some tools now offer logpoints, which are basically print() inserted via a breakpoint UI rather than in your code where you can forget to remove them
        kyawzazaw 6y ago
        Oh please tell me about those tools.
        Macha 6y ago
        VS Code and Firefox Developer Tools are the two I'm aware of with actual support. Also some tools you can adhoc it as a conditional breakpoint by basically putting "print(whatever); return false" as the condition
        maccard 6y ago
        Visual studio does trace points [0] [0] https://docs.microsoft.com/en-us/visualstudio/debugger/using-tracepoints?view=vs-2019 https://docs.microsoft.com/en-us/visualstudio/debugger/using...
- klyrs 6y ago
  > in pycharm [0] you can even execute your print statements in the debugger if you so wish In my experience, debuggers are really good to expose hidden control flow. But usually, I know the flow, and using a debugger for human-in-the-middle print statements is just going to slow me down. Worse, those print statements are ephemeral, so I'm disinclined to write a nice formatter. Print debugging leverages the language -- want to print in a certain condition? Easy. Have a recursive structure, an array, or a graph that you need to investigate? A naked print sucks, a custom formatter is great. Need to check some preconditions/postconditions? Do that in code. Don't try to check that stuff by hand in the debugger. Speaking personally... the only thing I like about icecream is that ic(foo) both prints and returns foo, because you can inject it into code basically for free. But I already have a solution to that: def ic(x): print(x); return x
purerandomness 6y ago
How is changing code simpler than literally clicking on the line number to set a breakpoint?
- magicalhippo 6y ago
  Depending on how complex your debugger is, it allows you to output values that might not be inspectable through the debugger. Especially computed values. Debug printing also allows you to debug programs running in environments where you can't attach a debugger. For example, maybe halting the program causes the bug not to trigger. Or it's a remote system where you cannot attach a debugger for various reasons. Or the bug only happens in the optimized build, which in say C/C++ can make it quite tedious to walk through with a debugger. Most of the time though I use print as "proactive debugging". Having detailed logs available is gold when customer calls with a blocking issue.
  - pjmlp 6y ago
    Most OS offer that with process tracing like ETW and DTrace.
  - stinos 6y ago
    Especially computed values Showing function return values automatically was really an eye-opener when I first encountered it.
- kevincox 6y ago
  You said "click", I need to leave my keyboard. Generally when I am coding I auto-run the tests on save. This means that to printf-debug I just add a message or two (and if I am coding I might already have a couple of useful ones lying around) and save. Then in less than a second I have a trace trough my program in the terminal. If I want to inspect a different variable I just add another print and run again. With a debugger I need to kill my auto-run command, run the program, set breakpoints, type to see what variables I want to inspect, maybe switch stack frames, maybe step through a bit. In my mind printf is like an automated debugger. I just put the info I want to see into the program and it does all of the printing for me. And when I find the problem I can just fix it and I am back to my edit-test cycle. I'm not saying that there are no use cases for a debugger. For example I find variable-modification breakpoints very useful. As you mentioned if your edit-run cycle is slow then it may be faster to inspect a new variable in the debugger than adding another print statement. But when I just want to inspect values in my program I find printf sufficient and lower overhead. I'm sure part of my problem is that because I rarely use a debugger I am not as efficient, but I also think that printf-debugging is a very effective workflow for a wide variety of issues.
josalhor 6y ago
The same thing happens all over Software really. Just because a tool is powerful is looked up as superior, or better. The main argument that I have seen is that in print debugging you are relying on the program being executed in a non-descriptive/non-declarative fashion. I legitimately believe print debugging is incredibly powerful (With a simple print I can check if a function is being called, how many times, if the value has the value I expected and the only requirement I need is to be able to see the stdout of the process. I say that is fantastic! The real world is all about cost analysis. How much value can I get from a tool vs setup and running cost. The cost of print debugging is incredibly small.
- marcosdumay 6y ago
  > The main argument that I have seen is that in print debugging you are relying on the program being executed in a non-descriptive/non-declarative fashion. Breakpoints are way worse on this dimension.
- tstrimple 6y ago
  Print debugging has all of those features and is natively built into just about every programming language in existence and doesn’t require any additional libraries or tools.
andix 6y ago
Because you shouldn’t have to change code, just to debug it. It’s okay though to add verbose logging as a feature. But just adding some print statements to debug code and remove them afterwards, is dangerous (you release sth different than you debugged).
- Consultant32452 6y ago
  ############################# What? #########################
- 0xFFFE 6y ago
  I do it in a different branch & discard it afterwards. Having said that, I never meant print() should be used in place of a proper debugger. All I am saying is they both can complement each other and each one has its place & value. As for me, I find it quicker to add a few print statements and get a rough idea before firing up a debugger(if required). May be others are more proficient in using debuggers. But print() works for me.
- ben-schaaf 6y ago
  As opposed to software breakpoints which change your compiled binary at runtime in order to debug it. Even if you're using hardware breakpoints you're still changing what the CPU is doing and can easily make multi-threading bugs disappear.
P_I_Staker 6y ago
Depending on the use case it can be a sign that they don't understand how to debug efficiently. Not that this is something you should judge someone for.

by 0xFFFE 6y ago

Absolutely, I don't understand why using print() or its equivalent in other languages is looked down upon. It's quick way to narrow down the "area of search" before bringing in the big guns.

yoz-y 6y ago

It definitely has its place. The problem is mostly that you have to actually change your code to debug it, and then remember to change it back.

maccard 6y ago

> It's quick way to narrow down the "area of search" before bringing in the big guns. What are the big guns? with a debugger, I can stick a breakpoint and look at the entire state of everything. Given we're talking about Python, in pycharm [0] you can even execute your print statements in the debugger if you so wish. If you get the location wrong, or want to see what's going on elsewhere you can just continue execution and use another breakpoint. This is even more important if you have a long compile/deploy cycle (I work in games, and rebuilding and deploying to a console can be a >10 minute iteration time) [0] https://www.jetbrains.com/help/pycharm/part-1-debugging-python-code.html#start-debugger-session https://www.jetbrains.com/help/pycharm/part-1-debugging-pyth...

ZaoLahma 6y ago
Sometimes sticking the debugger into the wheel makes stuff come flying over the handle bars in spectacular ways that have nothing to do with what you wish to observe. You might not even know which wheel to jam the debugger stick into, if the behaviour is complex. In these cases prints work well as a less intrusive way to get a rough idea of what is going on.
- maccard 6y ago
  I don't understand your wheel analogy, sorry. > You might not even know which wheel to jam the debugger stick into, if the behaviour is complex. If you don't know where to put a breakpoint, how do you know where to put a print statement?
  - Macha 6y ago
    Imagine putting breakpoints in multiple tight loops in the stage of narrowing the search space. Imagine how many times you need to click next. A conditional breakpoint will only help if you know the condition you're looking for, but there's stage before that of "Well, what looks strange during execution". Also for multithreaded code, stopping one thread dead for long enough for a human to investigate it can inadvertently resolve all sorts of race conditions.
    - sebastialonso 6y ago
      What I imagine Macha is arguing for is that the cost of using print is extremely small, smaller at least than breakpoints. No one is saying breakpoints are useless, sometimes printing is 'cheaper' in time and effort in order to locate the region code of code in which using breakpoints is cheaper.
      - Macha 6y ago
        Yes, print() and breakpoints are different tools with different uses and there's cases where one is superior to the other. This is why some tools now offer logpoints, which are basically print() inserted via a breakpoint UI rather than in your code where you can forget to remove them
        kyawzazaw 6y ago
        Oh please tell me about those tools.
        Macha 6y ago
        VS Code and Firefox Developer Tools are the two I'm aware of with actual support. Also some tools you can adhoc it as a conditional breakpoint by basically putting "print(whatever); return false" as the condition
        maccard 6y ago
        Visual studio does trace points [0] [0] https://docs.microsoft.com/en-us/visualstudio/debugger/using-tracepoints?view=vs-2019 https://docs.microsoft.com/en-us/visualstudio/debugger/using...
klyrs 6y ago
> in pycharm [0] you can even execute your print statements in the debugger if you so wish In my experience, debuggers are really good to expose hidden control flow. But usually, I know the flow, and using a debugger for human-in-the-middle print statements is just going to slow me down. Worse, those print statements are ephemeral, so I'm disinclined to write a nice formatter. Print debugging leverages the language -- want to print in a certain condition? Easy. Have a recursive structure, an array, or a graph that you need to investigate? A naked print sucks, a custom formatter is great. Need to check some preconditions/postconditions? Do that in code. Don't try to check that stuff by hand in the debugger. Speaking personally... the only thing I like about icecream is that ic(foo) both prints and returns foo, because you can inject it into code basically for free. But I already have a solution to that: def ic(x): print(x); return x

purerandomness 6y ago

How is changing code simpler than literally clicking on the line number to set a breakpoint?

magicalhippo 6y ago
Depending on how complex your debugger is, it allows you to output values that might not be inspectable through the debugger. Especially computed values. Debug printing also allows you to debug programs running in environments where you can't attach a debugger. For example, maybe halting the program causes the bug not to trigger. Or it's a remote system where you cannot attach a debugger for various reasons. Or the bug only happens in the optimized build, which in say C/C++ can make it quite tedious to walk through with a debugger. Most of the time though I use print as "proactive debugging". Having detailed logs available is gold when customer calls with a blocking issue.
- pjmlp 6y ago
  Most OS offer that with process tracing like ETW and DTrace.
- stinos 6y ago
  Especially computed values Showing function return values automatically was really an eye-opener when I first encountered it.
kevincox 6y ago
You said "click", I need to leave my keyboard. Generally when I am coding I auto-run the tests on save. This means that to printf-debug I just add a message or two (and if I am coding I might already have a couple of useful ones lying around) and save. Then in less than a second I have a trace trough my program in the terminal. If I want to inspect a different variable I just add another print and run again. With a debugger I need to kill my auto-run command, run the program, set breakpoints, type to see what variables I want to inspect, maybe switch stack frames, maybe step through a bit. In my mind printf is like an automated debugger. I just put the info I want to see into the program and it does all of the printing for me. And when I find the problem I can just fix it and I am back to my edit-test cycle. I'm not saying that there are no use cases for a debugger. For example I find variable-modification breakpoints very useful. As you mentioned if your edit-run cycle is slow then it may be faster to inspect a new variable in the debugger than adding another print statement. But when I just want to inspect values in my program I find printf sufficient and lower overhead. I'm sure part of my problem is that because I rarely use a debugger I am not as efficient, but I also think that printf-debugging is a very effective workflow for a wide variety of issues.

josalhor 6y ago

The same thing happens all over Software really. Just because a tool is powerful is looked up as superior, or better. The main argument that I have seen is that in print debugging you are relying on the program being executed in a non-descriptive/non-declarative fashion. I legitimately believe print debugging is incredibly powerful (With a simple print I can check if a function is being called, how many times, if the value has the value I expected and the only requirement I need is to be able to see the stdout of the process. I say that is fantastic! The real world is all about cost analysis. How much value can I get from a tool vs setup and running cost. The cost of print debugging is incredibly small.

marcosdumay 6y ago
> The main argument that I have seen is that in print debugging you are relying on the program being executed in a non-descriptive/non-declarative fashion. Breakpoints are way worse on this dimension.
tstrimple 6y ago
Print debugging has all of those features and is natively built into just about every programming language in existence and doesn’t require any additional libraries or tools.

andix 6y ago

Because you shouldn’t have to change code, just to debug it. It’s okay though to add verbose logging as a feature. But just adding some print statements to debug code and remove them afterwards, is dangerous (you release sth different than you debugged).

Consultant32452 6y ago
############################# What? #########################
0xFFFE 6y ago
I do it in a different branch & discard it afterwards. Having said that, I never meant print() should be used in place of a proper debugger. All I am saying is they both can complement each other and each one has its place & value. As for me, I find it quicker to add a few print statements and get a rough idea before firing up a debugger(if required). May be others are more proficient in using debuggers. But print() works for me.
ben-schaaf 6y ago
As opposed to software breakpoints which change your compiled binary at runtime in order to debug it. Even if you're using hardware breakpoints you're still changing what the CPU is doing and can easily make multi-threading bugs disappear.

P_I_Staker 6y ago

Depending on the use case it can be a sign that they don't understand how to debug efficiently. Not that this is something you should judge someone for.