Because I have nested loops and only want to see certain cases and I'm not smart enough to set up conditional breakpoints or value watching

because, sometimes, having your program vomit all over your console is the best way to remain focused on the problem.

because sometimes you need to investiagte an issue that happens only on the production machines, and you can't/shouldn't setup debugging on those.

Try debugging a distributed embedded real time system which crashes when you are in a breakpoint too long because the heartbeat doesn't respond

Because it takes 3 hours to reach the error and I’ve got other shit to fix.

Debugger good for microscopic surgery, log stream good for real time macro view. Both perspectives needed.

As someone who has done a lot of debugging in the past, and has also written many log analysis tools in the past, it's not an ether/or, they complement each other.

I've seen a lot of times logs are dismissed in these threads recently, and while I love the debugger (I'd boast that I know very few people who can play with gdb like I can), logs are an art, and just as essential.

The beginner printf thing is an inefficient learning stage that people will get past in their early careers after learning the debugger, but then they'll need to eventually relearn the art of proper logging too, and understand how to use both tools (logging and debugging).

There's a stage when you love prints.

Then you discover debuggers, you realize they are much more powerful. (For those of you who haven't used gdb enough, you can script it to iterate stl (or any other) containers, and test your fixes without writing any code yet.

And then, as your (and everyone else's) code has been in production a while, and some random client reports a bug that just happened for a few hard to trace events, guess what?

Logs are your best friend. You use them to get the scope of the problem, and region of problem (if you have indexing tools like splunk - much easier, though grep/awk/sort/uniq also work). You also get the input parameters, output results, and often notice the root cause without needing to spin up a debugger. Saves a lot of time for everyone.

If you can't, you replicate, often takes a bit of time, but at least your logs give you better chances at using the right parameters. Then you spin up the debugger (the heavy guns) when all else fails.

It takes more time, and you often have a lot of issues that are working at designed in production systems, and a lot of upstream/downstream issues that logs will help you with much faster.

I found debuggers practically unusable with asynchronous code. If you've got a timeout in there, it will break, when you arrive at a breakpoint.

Theoretically, this could be solved by 'pausing' the clock that does the timeouts, but that's not trivial.
At least, I haven't seen it solved anywhere yet.

I mean, I'm still hoping, I'm wrong about the above, but at this point, I find it kind of ridiculous that debuggers are so popular to begin with.
Because it implies that synchronous code or asynchronous code without timeouts are still quite popular.

Debugger? I hardly know er

I have to print f to show respect.

I still use print as a quick "debug" its just convenient to have multiple prints in the code when you're iterating and changing code.

Depends on the language and platform as well as how asynchronous things are. For example, lots of platforms have little to no debugging for scripting languages. I write a lot of Groovy on a platform that has a debugger that is mostly too much trouble to connect my IDE to since the platform can't run locally. But even then it doesn't debug the Groovy code at all.

And with asynchronous stuff it's often difficult to tell what something isn't running in the right order without some kind of debug logging. Though in most cases I use the logger rather than printing directly to the console so that it can be left in and just configured to only print if the logging level is set to debug which can be configured based on the environment.

Quick printf vs. setting up conditions.

You can't run a debugger on a customer's machine.

Embedded Oldster : "Of course, we had it rough. I had to use a single blinking red LED."

Unix Oldster : "An LED? We used to DREAM about having an LED, I still have hearing loss from sitting in front of daisy wheel printers."

Punch-card Oldster : "Luxury."

Debuggers are for when you hit a problem with your code. Logs are for when someone else hits a problem with your code.

not all problems are worth busting out the heavy machinery (until they are)

I use Unreal quite alot and while I do print stuff to the log, for rapid prototyping I print string because it saves me precious seconds. Finished products will have logging for alpha testing since there's alot of log spam

Because, sadly, I more often than not do NOT have access to a debugger.

Learning how to write good debugging print messages is a skill. And nicely transfers to writing good debug log messages. Which makes diagnosing user issues much easier.

Uhh, I'm too lazy to learn all the GDB commands.

You're gonna want logging in production...

If you’re debugging a react re-render for example where the error happens on the 7th re-render then having it pause with the debugger 7 times can be annoying.

The issue is a debugger will trigger every time. In video games at least you have code that runs as over and over again in tick. Putting debugger breakpoints in that would be useless most of the time. Print is where it's at for ticking/timer debugging.

I honestly need to remember the debugger exists. They weren't common for interpreted languages when I got started.

Coming off as a noob here, but how do you actually utilize the debugger.

Mostly working on python stuff in VS Code, sometimes I just run the code and look at the error. Sometimes I try the debug and run option but it acts the same as just running the code; there's some stuff like variables window but I don't know how to utilize the information to debug.

Because if you invested a lot of time on carefully choosing the places where printf should be to get all the info you need, you just need to unset NDEBUG and voilà everything that you need is there again.

I used to work on a debugger. It was called TotalView, and it was a really stellar multiprocess, multithread debugger. You could debug programs with thousands of cores and threads. You could type real C++ code to inspect values, inject code into a running process, force the CPU to run at a given line, like a magic goto. But we had a saying "printf wins again". Sometimes you just can't get the debugger to tell you what you need.

Because for all the love I have for NGRX, debugging it is kinda hard.

The debugger can't handle the chonkers app I work on.

Later on when I want to look productive I’ll delete all those printfs then pay myself on the back for committing a lot of code changes that sprint and for reducing our log storage costs by 75%

I rarely use the debugger. When I do it's because I'm tired and I always regret it tbh. It's just a waste of time and clutters my screen.

The fastest way by far is to simply read and think. You have to do it any way.

The print is the last resort, I tend to use it maybe once per day. Doesn't clutter my screen and works with the shortcuts I'm used to. Totally flexible. Can comment out and share with team or reuse later. The issue is often immediately clear.

For example today I used it on a position after a multiplication with a matrix. I didn't explicitly convert it from a float3 to a float4, so w was 0, and it caused it to rotate instead of translate the position vector. Once I printed it it became clear.

Had I just read the code again and thought about what it was actually doing I would've found it more efficiently.