That's funny. I remember using interactive debuggers all the time back in the '90s, but it's been a long time since I've bothered. Logging, reading, and thinking is just... easier.

▲

TheRoque 6 days ago | parent | next [-]

Really ? I find myself thinking the opposite. My program always runs in debug mode, and when there's some issue I put a breakpoint, trigger it, and boom I can check what is wrong. I don't need to stop the program, insert a new line to print what i _guess_ is wrong, restart the program from scratch etc.

Properly debugging my stack is probably one of the first things I setup because I find it way less tedious. Like, for example, if you have an issue in a huge Object or Array, will you actually print all the content, paste it somewhere else and search through the logs ? And by the way, most debuggers also have ability to setup a log points anyways, without having to restart your program. Genuinely curious to know how writing extra lines and having to restart makes things easier.

Of course I'm not saying that I never débug with logs, sometimes it's require or even more efficient, but it's often my second choice.

▲

marssaxman 5 days ago | parent | next [-]

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.

	▲	TheRoque 5 days ago \| parent [-]
		Thanks for the detailed answer. Indeed I also worked on embedded a long time ago, and the debugger was often the last resort because the debug pins weren't always accessible.

▲

LandR 5 days ago | parent | prev [-]

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.

▲

globular-toast 5 days ago | parent | prev [-]

Yeah, I remember learning to use gdb when I was beginning in the early 2000s. I totally thought I was "levelling up" as a programmer and to be honest felt kinda badass with all those windows open in Emacs. But I've found that the number of times I actually resorted to using the debugger has been so small I don't remain fluent in it's use. What am I supposed to do? Write more bugs? On the other hand, I'm always ready to read, think and put in some print/log statements.