[selfhoster11]

I think that parent’s point was that debugging is an exceedingly powerful tool, and therefore leaving it out of your toolset by definition makes you less powerful as a programmer. It’s not even such an esoteric skill - operating the simplest kind of a GUI debugger is maybe learning 5-6 different actions, and the IDE often takes care of the details of setting up the debugger for you.

[jdbernard]

I don't know that I'm convinced of that point though. I've been developing software professionally for almost 20 years and my usage and reliance on a debugger has decreased over time. At the moment, I think it's been probably three months since I've last used one.

[bornfreddy]

This. I used to use debugger all the time as a more junior dev, but I haven't used one in years now. Also, over time I spend more and more time writing tests. When there's a problem a simple print, echo, console.log or whatever is usually enough to solve it quickly.

The problem that debuggers solve is simply not a big problem anymore, in my experience. Definitely not worth the setup hassle when actively working on multiple platforms.

[wruza]

On the contrary, I find a common debugger (see questions below) an underwhelming experience, not a powerful tool.

Can it:

- assign (scenario, subsystem, level, description) to breakpoints and watches, so they can be turned on/off or selected in groups for debugging without removal?

- commit these scenarios of bps and watches into a repository?

- edit/read them in a textual form to patch or share over an IM?

- store traces of previous sessions and diff them to find out what changed?

Does anything even remotely similar exist? Most debuggers are just test-pause-and-inspect tools with “integration” in the form of eval on mouse hover. Their ux and dx sucks and the only reason I could find to use them were slow build times and too low-level runtimes, which are no more today.

Pretty sure most people avoid debuggers not because they are too hard to learn (they aren’t), but because they are too dumb to be useful, given that you can ‘if (cond) log.level(…)’ and restart instantly.

[KallDrexx]

> - assign (scenario, subsystem, level, description) to breakpoints and watches, so they can be turned on/off or selected in groups for debugging without removal?

In Jetbrain's tools they definitely can. I can

* create a bunch of breakpoints

* give them descriptions

* only have them break on execution under certain conditions (conditions stated via the programming language being debugged, so `my_struct.some_func() == 5`)

* disable and enable breakpoints with a click of a button

* have a breakpoint only become active when another breakpoint got hit (and therefore only cause the debugging logic to execute in certain code paths

* Have a breakpoint not stop execution when it gets hit, which is useful because I can then

* Log when a breakpoint gets hit, including it's stack trace (so I can see exactly the flow that got me to that breakpoint)

* Evaluate some variable when a breakpoint is hit and log that evaluation.

All of this with an extremely simple UI that can be manipulated without any recompiles and while the application is running. I've gotten tons of value of debugging complex scenarios in both C# and Rust via this constructs.

So while I'm not going to convince you that debuggers are worthwhile, to call them "too dumb to be useful" is pretty naive.

[wruza]

Well, this is good to learn. I skimmed through intellij debugger docs before writing that comment and didn’t find anything like that. Thanks!

[KallDrexx]

A screenshot showing the UI for this is https://resources.jetbrains.com/help/img/idea/2022.2/cl_brea... (from https://www.jetbrains.com/help/clion/using-breakpoints.html). Though that screenshot doesn't show the description field, which definitely exists on my CLion build.