[maccard]

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]

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]

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]

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]

Oh please tell me about those tools.

[maccard]

Visual studio does trace points [0]

[0] https://docs.microsoft.com/en-us/visualstudio/debugger/using...

[Macha]

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]

> 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.

[maccard]

> Imagine putting breakpoints in multiple tight loops in the stage of narrowing the search space.

If you have enough loops to make breakpoints impossible to use, you've likely got enough log output that you're not going to be able to parse. You're almost certainly going to look for other ways of narrowing the search space.

> stopping one thread dead for long enough for a human to investigate it can inadvertently resolve all sorts of race conditions.

Stopping one thread for long enough to do console IO has the same effect. Especially if you're using python, you'll need a lock to synchronise the print statement across your threads!

[Fethbita]

Today I was trying to solve the exact scenario in the second example. A multi threaded program had a race condition that would sometimes occur. printing numbers helped a great deal. Might also be that I'm not that proficient with my debugger even though I use that more than anything.

[Franciscouzo]

> Imagine how many times you need to click next

Once or twice? Any sane debugger has a way to disable the breakpoint.

[Macha]

Then you overshoot the iteration that has a problem

[kyawzazaw]

As someone who help teaches intro level CS class, debuggers can be too OP.