Hacker News Reader

Comment by judgardner | Hacker News Reader

Whats even better than print for debugging is using a debugger...

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.

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.

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

Whereas I see this pattern more with senior engineers.

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

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.

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.

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.

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

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

So does repl, to be fair.

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.

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

If I have easy access to a debugger. It’s extra work to hook things up to a debugger, and there are certain restrictions that may apply (attach too late if process launch is not under our control, program may behave differently, etc.). If I do have access to a debugger, often I will just do “printf debugging” there by setting a breakpoint and adding an action to “p someVariable; c”. Usually I treat my debugger a sort of IPython for statically compiled languages, to mess around with and inspect values as programs are executing.

I have yet to come across a situation in which it is not worth the effort to figure out how to attach a debugger to a piece of code I'm modifying.

Again, attaching a debugger is occasionally not helpful–for example, if you're trying to figure out why your program isn't loading certain plugins at launch, you trying to attach the debugger may happen after this step occurs. So you don't get to debug this process.

Or if an issue happens in your staging environment but not locally. That happened to me just yesterday, and a simple print statement gave me the information I needed to resolve the issue.

I probably could have attached a remote debugger, and executed the relevant function a few times until my request got routed to the right process in the cluster, but that honestly would have taken me more time than just committing the print statement and letting CI take it away.

That seems like a good thing to use logging for, instead of a print statement.

But you're right, figuring out a dev / prod discrepancy in already-running code is a case where a debugger is not as useful.

Exactly, and in the replies it is really obvious what the debate is really colored by.

In many cases there is no debugger available for someone's favorite platform. And so they "hate debugging". Go programmers, javascript people (where you can't do client->server debugging, but really, really have to), ...

How many Java programmers don't use debuggers ? How many C# developers ? Those languages have excellent debuggers. Python, C/C++, ... decent at best. Go/Javascript/... dismal debugging support.

> Javascript/... dismal debugging support.

Eh? I thought JavaScript debuggers were pretty good.

I always compare my React debugging experience to something like GWT debugging from 5 years back ... and I find it very lacking indeed.

Doesn't quite work when debugging a distributed system, though. You end up adding a lot of "distributed print", AKA logging.

Fair enough, but attaching multiple debuggers across several interacting components with conditional breaks gets me there faster than incrementally inserting progressively more print statements, in a dev environment. Proper logging is a given doping out problems in a production system to then verify and correct in dev.

Logs aren't a bad thing and they aren't going away. Whoever let's you setup debuggers on prod should be fired.

Agreed, great logs are great.

My comment explicitly stated dev environment, not prod, for debugger usage.

No one said otherwise, and the comment you replied to specifies "in a dev environment". The language you are using is unnecessarily combative: this is likely to inhibit the adoption of your ideas.

Only with python. With LISP it's the common case to debug prod.

I would rather argue that such incompetent managers who speak such nonsense need to be fired.

Smalltalk folks will debug in production too. Although to be fair, Smalltalk folks will write whole programs in debug in development.

Sure. Arguably Smalltalk is a LISP, just with non-Lisp syntax. It actually was prototyped in lisp first.

Sometimes having a debugger on prod is the right answer.

"The Remote Agent software, running on a custom port of Harlequin Common Lisp, flew aboard Deep Space 1 (DS1), the first mission of NASA's New Millennium program. Remote Agent controlled DS1 for two days in May of 1999. During that time we were able to debug and fix a race condition that had not shown up during ground testing. (Debugging a program running on a $100M piece of hardware that is 100 million miles away is an interesting experience. Having a read-eval-print loop running on the spacecraft proved invaluable in finding and fixing the problem. The story of the Remote Agent bug is an interesting one in and of itself.)

"The Remote Agent was subsequently named "NASA Software of the Year"."

http://www.flownet.com/gat/jpl-lisp.html

http://ti.arc.nasa.gov/m/pub-archive/176h/0176 (Havelund).pdf

There is much more to logging than print statements. I have yet to run into production code which uses vanilla stdout print statements for logging.

Reply on news.ycombinator.com