Hacker News Reader

Comment by deergomoo | Hacker News Reader

I’ve never understood why anyone would choose to debug by printing and logging if they have a good debugger available to them.

My day job is mostly PHP (yeah yeah, I know) and the general attitude towards Xdebug in the community seems to lie somewhere between apathy and active avoidance.

To me, a debugger is such an invaluable tool not only for identification of bugs but also for familiarising oneself with new code. The value of being able to not only trace execution from start to finish but also to modify state in a running program is immense, and gives me a small taste of what Lisp folks rave about.

Littering print statements everywhere feels like banging rocks together when there’s a perfectly good lighter in your pocket.

View on HN

It depends on what you're doing. I find console statements helpful when testing out a new function that you don't necessarily expect to misbehave so I check the internal state is correct without having to stop the code.

Debuggers provide much more information, but stopping and stepping through the code is much more time intensive than printing out variables at various points and running the function and doing a quick double check that they're correct.

It also allows you to check the state of the program earlier for problems that may only emerge after the fact. Instead of having to stop what I'm doing and retry and step through with the debugger, I can just look back at the log and see what went wrong where.

I think both debug logs and debuggers have valuable use cases.

Tracing debuggers give you the best of both worlds. I've recently started using Flow-storm [0], by @jpmonettas), and it's been quite transformative. You can still easily see the values flowing through your system (better than just "prints"), and it can handle multi-threaded / async scenarios quite nicely. You don't need to manually step through code, you can just "see" your data flow, and when you have loops or some other form of iteration, you can see the data for each pass. Coupling this with a good data visualization tool (such as Portal [1]) really feels like magic. I've been doing Clojure for quite a few years now, and was very happy with my plain REPL-driven workflow, but this is way better.

[0] https://github.com/jpmonettas/flow-storm-debugger

[1] https://github.com/djblue/portal

That sounds like a really cool idea! Thanks for letting me know it exists

Awesome tools.

Personally I can't imagine coding in clojure without scope capture

https://github.com/vvvvalvalval/scope-capture

More and more software, especially on the web, is asynchronous microservices.

Debuggers are basically useless for both of those imo.

Debugger break points introduce synchronous behavior into your async application, which basically forces race conditions to fail when debugging.

And I'll admit to not being a debugger expert but I don't know of any that can watch multiple executibles at once.

There shouldn't be a need to connect to another service during debugging except maybe to validate that an external service stands by its published contract. A debugger (nor printf) does not seem like the right tool for that job, though.

If you're not sure which service is causing the error, combing a log output from the two services is much easier than debugging each service separately, is my point.

1. How does this really differ from debugging both services at the same time and attaching logpoints?

2. Microservices is a team separation technique, allowing different team to live in isolation, sharing only API documentation. It's the same as regular web services, except within a single organization instead of across organizations. If you happen to have access to the code (not a guarantee!), are you really going to be able to jump into a codebase you're not familiar with to start adding print lines with more expediency than other possible approaches?

Re 2: tell that to the company I used to work with. Management heard microservices are good? Then we should have nano services. They mandated that we split things up super small, by functionality, even if there was only one team working on that.

Microservices are more than just an organizational abstraction. They allow you to scale up services as needed for one thing.

Yes, that's right. Teams not needing to communicate, beyond API contracts, allows them to scale the service they provide. When sharing code in a monolith then you have to meetings when you want to make changes that impact other developers, and that will soon take your whole day when there are thousands of workers, leaving no time to do anything. That leaves service that cannot scale.

More simply, it takes how the macro economy scales software (and, really, most everything) and tries to apply the same processes in the micro.

A service layer is not necessary to have an API contract.

But you do need people providing service in order to emulate macro services in the micro.

I honestly can't make heads or tails of this. Can you expand on what you mean?

Or God forbid those Next.js apps where the same line of code is ran on the server, streamed to the client, and then ran again on the client via rehydration. 3 different potential sources of failure and you have to debug them simultaneously.

IMO, this is one of the reasons that architectural style is not actually very good...

There are various kinds of debugger. For investigating systems like this I think you want a trace / time travel based debugger, like eg FlowStorm in the Clojure world.

This just means that debuggers have to catch up. Anything that runs on a CPU is also debuggable, and if it's too much hassle, the debuggers need to improve. Debuggers are much more than just stepping through code and setting breakpoints, they are (or should be) "interactive program state explorers and visualizers".

(IMHO no programming language should add features which make interactive debugging harder, it's never worth it in the long run)

I don't understand the problem, why can't you simply run the debugger of your choice multiple times, each for one process?

Sure.

But I also might not be running one of the services in my personal dev environment.

I use both, they have different purposes. I find printf-style debugging to be much faster for bisecting the control flow, and the vast majority of bugs I see are of this type.

Debuggers tend to be more useful in cases of corrupted state that isn't the result of broken control flow logic. These are much rarer, usually the product of something like broken bit-twiddling logic. And these days that kind of code is rarely written manually. When I write a non-trivial data container, I usually provide a standard public method that does a deep inspection of the integrity and consistency of the internal state. These are much too expensive to use as a typical assertion, but turning this on usually isolates the problem so well that a debugger isn't required to figure out what went wrong.

I used to use debuggers a lot more than I do now because the nature of the typical bug has changed. The types of bugs are also much less diverse than they used to be.

One of the great UX features of printing is that it is a quick way to have an auditable form of state over time. I look at states 1-n, compare and contrast, which my debuggers don't make as easy.

I'd add many people don't work in languages with good debuggers. I work in TS and the debugging async node code is an absolutely garbage experience in many cases.

It's because both are great for specific tasks.

If I want to check that the dependency injection engine creates & disposes correctly while navigating the app, I only need printing.

If I want to intercept some process and check value on the fly, or even change it, debugger is the way to go.

It's kinda ironic that you're discarding the matches because you have a good lighter.

For many nontrivial debugging tasks. You need to record a lot of past context - e.g. you can put a breakpoint when a bad decision gets made, but the data causing this decision likely accumulated over a few tens/hundreds of previous iterations - and in particular one bad iteration that you don't (yet) know how to characterize. In such a case, setting up watches and pressing F5 a hundred times to get to bad iteration is inferior to adding a print/log and scrolling back to it.

It's not one or the other, most debug sessions will also include some sort of adhoc logging.

Also "modern" debuggers ("modern" as in "this century") offer a lot more than just simple on/off breakpoints: conditional breakpoints, data read/write breakpoints (e.g. who wrote this broken piece of data), "tracepoints" which don't stop execution but instead log out a message or run some scripted action, etc etc...

A good debugger is essentially an interactive program state explorer and visualizer, ideally it would be fully integrated with the actual development process (e.g. edit, compile, run, break somewhere to inspect program state, tweak some code while program is suspended, rewind a program state a bit and continue running with the modified code, rinse, repeat...).

The problem is that the debugger conditional logic has to be written outside the local context of the code, and probably in a different language to boot. For example, in Xcode, you’re entering commands into a tiny box in the breakpoint popup that won’t actually tell you if you got the syntax wrong or not.

guess im lucky to be a java dev then lol

Which python debugger with these qualities? Which Javascript debugger? Which Go debugger?

Seriously asking; I am well versed in everything gdb, but I often revert to logging and "import pdb; pdb.breakpoint()" when I have to debug Python.

Jetbrains - never leave home without it.

you can make a conditional breakpoint

You don't need to litter print statements, you can litter log statements :D

I can't even remember when was the last time I was on a project where debugging would've been even a bit doable. Maybe, just maybe, during development when it's running on my computer.

But it worked on my computer, that's why it ended up in production =)

With proper logging (or just print statements) I can go in after the fact and narrow down what happened when it didn't work in a specific situation.

Having good log statements about what is being called with what value is invaluable when running a server and using log output to investigate issues.

They also let you troubleshoot a problem after it has happened. Logs can give information about the trigger, which the debugger can't do as it requires you to known what inputs caused the issue.

Can you please explain how does debugger can help in cases where you can't wait too long on a breakpoint because some thread or service waiting on it will fail? I do this many times at work in Java with intellij. I do fine with breakpoints most of the times but sometimes print statements is the only way to trace the thing.

From your comment I feel like I am missing better ways to debug.

Thing that annoys me is I know that debuggers could do a quick grab and dash.

Either stop the program snag the state of a variable and go. Or set a sample point where when it gets hit the debugger takes a sample of local state and continues. It aught to be able to do that within a few hundred clock cycles.

Myself I use error/debug printf, a command line interface, debugger, and sometimes an oscilloscope.

With error/debug printf I leave them in and just turn them on/off with a compiler switch. Over time they tend to evolve into something that provides good info on what's going on.

The command line interface allows me to inspect the program state on the fly and run tests on the fly.

The debugger allows me to do random look sees of what the program state is and follow the call tree.

Oscilloscope allows me to inspect/debug/verify timing issues.

My suggestion to you is implement a command line interface to you program so you can interact and inspect your program while it's running. It's really not hard at all. Implement commands as a table. { "command", handler, extra_data}

I don't know how this can be used in a very old and large codebase where no single person knows everything. There is too much state and unknowns at any given time. IDE with breakpoints does help explore the state through stack.

Use a log breakpoint? No need to recompile then, just add the breakpoint and do the thing again.

Log breakpoints are still kind of print debugging. I do add log breakpoints, even add conditionals on them, they however become a huge performance bottleneck in places and best way is to write a print statement in the code itself.

Are you able to also set a breakpoint in the service that’s waiting, such that it is also paused?

I’m really not familiar with Java but given PhpStorm supports concurrent debugging sessions I assume IntelliJ does too.

Print debugging can be much faster than using a debugger if you can figure out the problem and fix it on the first try. For more complex issues it makes sense to switch to a debugger.

I don't understand how that is possible. I would say the exact reverse. With print debugging you have to write the prints. With a debugger you just run the code. Especially with conditional breakpoints...

Takes me considerably less time to dump a bunch of prints than write (multiple) working conditional breakpoints. That said it's very problem dependent whether I use a debugger or logging (often a mix of both) and rr has considerably reduced some uses of logging for me.

You really shouldn't have to "switch to a debugger" as if it were a separate tool, but instead have it integrated into your development environment (e.g. "run" or "step into" should both be just key presses, and every "run" automatically runs inside the debugger so that you can pause and inspect program state at any time).

Sure, you shouldn't have to, but sometimes you're developing in an environment where adding a print statement + restarting + reproducing is faster than waiting for your IDE debugger to download whatever state information it needs (or whatever it's doing) l to render a prompt. For example, Xcode takes an eon to show a lldb prompt when you hit a breakpoint. Printing is instant every time.

Further, there are cases where variables are optimized out of builds so you have to add code to ensure they stick around (in which case you may as well print). Again, this applies to iOS development. Maybe others.

> I've never understood why anyone would choose to debug by printing and logging if they have a good debugger available to them.

Because logging provides a different experience and can be sometimes much faster. I can run the code once and then analyze all the collected information later. The log allows me to go back and forth very fast, or very quickly see that e.g. a 150th iteration went sideways even if I don't exactly know what to expect. Another area where logging is tremendously helpful is debugging concurrency related bugs.

Yep. Most debuggers also make it very hard to go backwards in time. Logs can be read in any order.

There’s a neat trick I like to do when I’m trying to triage a bug that only shows up with some input data. I’ll run the passing test and the failing test with detailed logging, then diff the logs to understand how the code is behaving differently in each case.

A jr programmer once asked how I know that N lines do what I expect without writing a test every 10 minutes. Logging is a form of unit testing. Logging can be thought of as unit tests for your specific context, decoupled from the logic (almost) entirely.

I have an expectation of state, the execution can be checked against that expectation via observation of the output (which usually has serialized state). It's not a fancy True False or checkmark, but it's an assertion (which constitutes a test of an expected state) nonetheless.

There are two junior developers in your anecdote. That’s not a test. It’s not even comparable to unit tests, much less a replacement for them.

If you want to define tests as something other than observed state, go ahead. The ad hominem looks like you took it personally.

A log statement isn't a unit test in the same way that apples aren't trees. A unit test is a discrete, runnable program that asserts some state about your program to be true, whereas a log is just some subsystem of your overall program that prints some output with no pass/fail condition.

You may have a unit test that makes assertions about logs though? I would definitely expect somebody that isn't a junior programmer to understand this.

> A log statement isn't a unit test in the same way that apples aren't trees

I don't think your explanation is compelling.

> a log is just some subsystem of your overall program that prints some output with no pass/fail condition.

The pass fail is interpreted. A unit test result is interpreted, be it with a big green/red or an exception or any other way you wish to express it.

Running something manually and checking the logs in an environment, when there is a reported issue, is modus operandi of every developer today. Did A happen and B happen and what did C say before exit? A looks good (because it has an expected state), etc.

> I would definitely expect somebody that isn't a junior programmer to understand this.

I didn't say logs were a replacement for unit tests (that's a previous poster's strawman). Regardless, they are a form of testing, because we use them to observe state after execution. Manual testing is testing, manual testing and observation of logs, is testing.

You explicitly said logging is a form of "unit test" which has a very specific meaning and a log is not it. Observing a log can obviously be part of an assertion in a test be it manual or whatever, but an assertion is not a unit test.

> A unit test is a discrete, runnable program that asserts some state about your program to be true

I would say "Observe the state of an execution stack". Tomato tomato.

> which has a very specific meaning

Unit testing is a methodology, not a specific thing.

How you observe it, be it through a pass fail indicator or a "This looks right", is immaterial. Splitting hairs on the output methodology does not change the utility.

The difference is that unit tests are checked automatically, and logs require manual inspection.

Eyeballing a log is often enough to convince myself that some code is probably correct. It’s not as thorough as a unit test, but better than nothing if you weren’t planning on writing a test anyway.

This can also be a great way to write your unit tests. Once you like what your code does in some situation, you can copy paste the input and expected output into a unit test to make sure you don’t break that correct behaviour later.

The other difference is that unit tests are usually quiet unless something is wrong but log statements are always noisy.

When there's too much noise it becomes harder to see what's happening.

You can turn down the log level but then you loose that visibility altogether.

Unit test frameworks are the modern, convenient, methodology to control bubbling up an output, when multiple assertions fail. This is what observing the red (suite failed) or green (suite succeeded) is.

Executing a suite requires a manual interaction (ie > run suite or > make build -> runs suite or > edit cron -> runs suite). In a way, all testing is still manual, but test suites allow us to scale testing, which logs do not (1million log files is impractical to use as testing output). That's why unit test frameworks are a good thing.

> My day job is mostly PHP (yeah yeah, I know) and the general attitude towards Xdebug in the community seems to lie somewhere between apathy and active avoidance.

From my experience, simply having xdebug enabled comes with a significant performance hit, which is why I generally avoid it unless I really need it.

I believe that’s mostly solved with Xdebug 3. The performance hit of having it enabled but not actively debugging was greatly reduced compared to 2.

>the general attitude towards Xdebug in the community seems to lie somewhere between apathy and active avoidance.

Every year more good engineers start refusing to interview for most php gigs if it's not FAANG. You're with what's left of the rest

Reply on news.ycombinator.com