[beatgammit]

I disagree. Most of the time, I find a debugger just slows me down. It's super helpful in some cases, but good logs can pinpoint problems far before a debugger can. Also, building in debug mode can change everything, so you may not even catch your bug, especially if it's concurrent in nature.

[marktangotango]

This idea that debugging with print statements is superior to using a debugger is simply false. Learn to use the debugger for your platform it will pay huge dividends throughout your career.

I regularly see pais+ of println debuggers debate and speculate while the guy with the debugger drills straight down to the issue, and fixes it.

[nayuki]

I think it is a fallacy to choose either printing or debugging. I forgot where I read this, but the two techniques are fundamentally different. A debugger lets you stop execution and examine data structures at one point in time. Printing lets you accumulate a log of one particular data structure over a span of time. I think these techniques are complementary and have different effectiveness on different problems.

[heavenlyblue]

Yep. They call it “tracing” in debugging and a good debugger will be able to directly catch and log the values of any variable at a particular line of code.

By using logging instead you’re reimplementing years of good work done by engineers before you.

[xxs]

>I find a debugger just slows me down

1st you have to add the useless print statements and after decades of programming a debugger is vastly superios in terms of 'debugging' when compared to printing. (Back in time basic had no debugger even)

Also printing is utterly useless for high concurrent code, as printing alters memory visibility, usually adds global sync, etc..

[a_t48]

Attaching a debugger will also change the behavior of concurrent code.

[xxs]

This would depend on the language/compiler/linker - take Java (which the article is about). Attaching debugger does nothing prior to adding a breakpoint.

The breakpoint would cause the method to be deoptimized, executed in the interpreter. Removing the breakpoint would allow the method to be optimized again.

Now obviously during stepping in, the thread would be blocked and not highly concurrent. However print statements just bare the concurrency.

[a_t48]

Let's face it - concurrency sucks to debug in general.

[shaklee3]

So does repl, to be fair.

[judgardner]

I think there are two use cases here, I was referring to debugging during development and a lot of replies are regarding troubleshooting an active prod system.

Of course we all hope for well thought out logging to troubleshoot issues we're seeing in prod.

I'm referencing an pattern I see with junior devs who simply use "printf debugging" in development instead of learning to use a debugger properly, even with distributed systems.

[akvadrako]

> an pattern I see with junior devs who simply use "printf debugging" in development

Whereas I see this pattern more with senior engineers.

[analognoise]

I don't use printf. I tie a pin to an assertion of the expected result, and watch it with an oscilloscope.

Get on my level, normies. /s