5 ms·

> 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

> 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...
      - maccard 6y ago
        > the cost of using print is extremely small, smaller at least than breakpoints. I don't think it is, at all. The cost of using print is re-running your applciation with a code change, whereas the cost of a breakpoint is re-running your application with a breakpoint. Clicking in a gutter in an editor, pressing a keyboard shortcut, or typing "b <line number>" into your debugger is no more time or effort than adding a print statement, and re-running your program.
  - kyawzazaw 6y ago
    As someone who help teaches intro level CS class, debuggers can be too OP.
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

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...
    - maccard 6y ago
      > the cost of using print is extremely small, smaller at least than breakpoints. I don't think it is, at all. The cost of using print is re-running your applciation with a code change, whereas the cost of a breakpoint is re-running your application with a breakpoint. Clicking in a gutter in an editor, pressing a keyboard shortcut, or typing "b <line number>" into your debugger is no more time or effort than adding a print statement, and re-running your program.
- kyawzazaw 6y ago
  As someone who help teaches intro level CS class, debuggers can be too OP.

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