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

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.

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)

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

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.

I almost exclusively debug via printf / logging, and I am so stupendously ignorant that I have even written and published a multi-platform interactive debugger, to go with the compiler I also wrote (one of several, but this one was the most successful). Make of that what you will, I suppose.

I imagine that it depends on the kind of software you are working on. I found debuggers helpful back when I was working on interactive GUI programs which had a lot of complex state, built in classic OOP style with lots of objects pointing at each other, but I have not done that sort of thing in a long time. In part, that's because I got seriously into functional programming, which left me with a much more rigorous approach to state transitions; but then I shifted from conventional software into embedded firmware, where you can sometimes stop the microcontroller and use a debugger via JTAG, but it's usually easier to just stream data out over a serial port, or hook an LED up to a spare pin and make it blink. The world doesn't stop even if you want the software to stop, so the utility of a debugger is limited.

After that I went to work for Google, building distributed software running across many machines in a datacenter, and I have no idea how you would hook up a debugger even if you wanted to. It's all logs all the time, there.

By the time that was over, I was thoroughly accustomed to logging, and attaching a debugger had come to seem like a nuisance. Since then I've mostly worked on compilers, or ML pipelines, or both: pure data-processing engines, with no interactivity. If I'm fixing a bug, I'm certainly also writing a regression test about it, which lends itself to a logging-based workflow. I don't mind popping into gdb if that's what would most directly answer my question, but that only happens a couple of times a year.

Also conditional breakpoints. I.e. break on this line if foo==5

I couldn't imagine going back to print statement based debugging. Would be a massive waste of time.

it's genuinely embarassing that the printf() diehards in this thread are not clear on this detail.

I guess that’s the difference. I do rails dev mostly and it’s just put a print statement in, then run the unit test. It’s a fast feedback loop.

Good, it's not just me.

I guess it's not a massive surprise given it's an HN forum and a reasonable percentage of HN candidates are doing LLM/AI stuff in recent cohorts, but it still means I have to apply a very big filter every time I open an article and people wax lyrical about how amazing Claude-GPT-super-codez is and how it has made them twice the engineer they were yesterday at the bargain price of $200 a month...

May it all die in a fire very soon. Butlerian jihad now.

Every single last link here is some form of an advertisement, why single out LLM-related ads?

Not to mention tracepoints (logging breakpoints), which are functionally the same as printf but don't require compiling/restarting.

And have since the mid 1990s at least…