grug know debugger good but grug often realize grug no need debugger on smaller cases and only run it when grug need it, grug try simple code like print and log first, if grug sad and no understand grug go for debugger
But you definitely should not be doing that if you have a good debugger as It's faster to click the line to add a break point and press play. You can SEE the state. And you can view other variables at the same time if something's looking whiffy, usually by just hovering your mouse. Plus see the entire call stack.
The thing that's boggling my mind about this is that if you know the line to add a log statement on, you know the line to add a breakpoint on. It's so much easier to just add a breakpoint.
In some languages if I saw someone adding a log statement while debugging I would immediately classify them as a junior programmer and start teaching them how to debug properly.
Either you are using a shitty language with a crap debugger or you need to learn how to use your IDE.
> Thus, I fully support high-level languages in which pointers are hidden and types are strong and the declaration of data structures does not require you to solve a syntactical puzzle generated by a malevolent extraterrestrial species. That being said, if you find yourself drinking a martini and writing programs in garbage-collected, object-oriented Esperanto, be aware that the only reason that the Esperanto runtime works is because there are systems people who have exchanged any hope of losing their virginity for the exciting opportunity to think about hex numbers and their relationships with the operating system, the hardware, and ancient blood rituals that Bjarne Stroustrup performed at Stonehenge.
If I want a debugger and see e.g. the complete variable scope at a breakpoint, I'll use a debugger. If I just want a very quick sanity check I'll use a simple print.
Once you enter debugger land you're there. When I'm currently not in the debugger but rather compiling and executing "for real", it seems more straightforward to me to not enter debugger land when I really don't need it. Personal preference.
There are scenarios, where 2 print statements can tell you more quicker, than breakpoints. You have to step through the breakpoints, right? 2 print statements in different parts of the control flow can tell me everything I need to know at a single glance.
This seems to be a common misunderstanding, but debuggers generally also support logpoints (print statements that you can add/remove on the fly without having to close, compile and restart the application).
I do like to step through code with a debugger when I need it. But that's rarely the case. The usual bug-hunt is something like: Do we go down path A or path B and whats the value of C before and after. Ideally, there is already logging in place that gives me exactly the info I need. If not, to me adding 2 prints or expanding the log usually seems just way more sane than spinning up a debugger, when I'm already looking at stdout/logs and I just need a tiny bit of additional info in there. Maybe I need a faster machine, lol.
Tracing is also a great tool, imho.
As for your point about logging being a fail condition, I was working on a distributed system where I had no control over which instance my code was running on. I would attach a debugger and make the same request a dozen times before the instance I had attached the debugger to processed the request. This wasn't a system I could setup a local instance of. I also couldn't reduce the instances to a single one because there were other devs, testers, data engineers working on it and the system did raster processing that regulary took 1-5 minutes. I resorted to log debugging.
The alternative is setting (sometimes many) breakpoints in different places and remembering what happened at each of them. Personally, I prefer reading a log.
I use debugger all the time when I run into pointer related issue, or some checking some tensors in deep neural nets etc.
In some cases, I throw debugger just to see what is going on.
However, I have had few cases where debugger slowed me down. If you are doing something in graphics that requires you debugging issues that spans multiple frames, sometimes it's easier to notice the value over a period of time and see why things are behaving that way. From there you can reason what might be causing the issue. It can be done frame per frame inserting multiple breakpoints, recording them and viewing them accordingly! However, I prefer simple logs in such cases.
I have used both approaches as time demanded.
The best systems are the ones that log just enough, but no more, whatever that means can be difficult to quantify. I find logs that are informative or actionable to an operator are the most useful, if a log entry appears more than once a minute and this entry is only useful for a developer of a particular submodule, it’s too chatty and likely an indication this module is not understood enough. If a system is doing its job it should for most of the time not say much. Getting to this state of log nirvana does however, as you say, require the best of developers.
Ah, the awkward "tween" stage of development. If you don't switch to the management track, you'll skin your knees enough times to learn when you need one and not the other.
or you are working in a domain where debug builds are intolerably slow.
So yeah console.logs are still quite common even if you have a great debugger because it’s the most accessible and laziest option.
But there’s something very rewarding about getting really good with a debugger and figuring things out quickly.