> Meanwhile many of the seniors around me are stuck in their ways, refusing to adopt interactive debuggers to replace their printf() debug habits, let alone AI tooling...

When I was new to the business, I used interactive debugging a lot. The more experienced I got, the less I used it. printf() is surprisingly useful, especially if you upgrade it a little bit to a log-level aware framework. Then you can leave your debugging lines in the code and switch it on or off with loglevel = TRACE or INFO, something like that.

▲

shmerl 6 days ago | parent | next [-]

I kind of had the opposite experience. I used to rely mostly on printfs and etc. but started using debugger more.

printf doesn't improve going up and down the call stacks in the debugger to analyze their chain (you'd have to spam debug printfs all around you expect this chain to happen to replace the debugger which would waste time). debugger is really powerful if you use it more than superficially.

▲

boredtofears 5 days ago | parent [-]

> you'd have to spam debug printfs all around you expect this chain to happen to replace the debugger which would waste time

It's not wasting time, it's narrowing in on the things you know you need to look for and hiding everything else. With a debugger you have to do this step mentally every time you look at the debugger output.

	▲	shmerl 5 days ago \| parent [-]
		Trying to guess what that chain is and putting printf's all around that path feels like doing a poor simulation of what debugger can do out of the box and unlike us - precisely. So I'd say it's exactly the opposite. If you only care about some specific spot, then sure - printf is enough, but you also need to recompile things every time you add a new one or change debug related details, while debugger can do it re-running things without recompilation. So if anything, printf method can take more time. Also, in debugger you can reproduce printf using REPL.

▲

ambicapter 6 days ago | parent | prev | next [-]

> printf() is surprisingly useful, especially if you upgrade it a little bit to a log-level aware framework.

What do you mean by this? Do you mean using a logging framework instead of printf()?

▲

cbanek 6 days ago | parent | prev | next [-]

This is absolutely true. If anything, interactive debuggers are a crutch and actual logging is the real way of debugging. You really can't debug all sorts of things in an interactive debugger, things like timing issues, thread problems, and you certainly can't find the actual hard bugs that are in running services in production, you know, where the bugs actually happen and are found. Or on other people's machines that you can't just attach a debugger. You need good logging with a good logging library that doesn't affect performance too much when it's turned off, and those messages can also provide very useful context to what things are going on, many times as good if not better than a comment, because at least the log messages are compiled in and type checked, as opposed to comments, which can easily go stale.

▲

TheRoque 6 days ago | parent | next [-]

Both are valid, if your code is slightly complex it's invaluable to run it at least once with a debugger to verify that your logic is all good. And using logs for this is highly inefficient. E.g. if you have huge data structures that are a pain to print, or if after starting the program you notice that you forgot to add some print somewhere needed.

And obviously when you can't hook the debugger, logs are mandatory. Doesn't have to be one or the other.

▲

twodave 6 days ago | parent [-]

> verify your logic

This is what unit tests are for.

▲

compiler-guy 6 days ago | parent [-]

And no one has ever written a buggy unit test.

	▲	ch4s3 5 days ago \| parent [-]
		That’s what the code is for.

▲

brongondwana 5 days ago | parent | prev | next [-]

This is why I trigger a segfault which dumps core at the spot where I had the printf when the conditions aren't what I want, so I can then open the debugger on the core (obviously: not if I have a copy of the input which can recreate it, if so then a debugger with a conditional breakpoint at the same spot is even better)

▲

lenkite 5 days ago | parent | prev | next [-]

Timing and concurrency issues are actually easier to discover in a debugger than using printf logging.

▲

JustExAWS 5 days ago | parent | prev [-]

Really? I’ve been using interactive debuggers since the days of Turbo C/Turbo Pascal in the mid 1990s.

Yes you need good logging also.

▲

evertedsphere 5 days ago | parent | prev [-]

it can get even better

https://rustc-dev-guide.rust-lang.org/tracing.html#i-dont-wa...