Debuggers are complicated and create dependency. How many developers do you see every day just sitting at their computer tapping "step" ... "step" ... "step" for hours.
I'll break out a debugger if all else fails, but it's not my first choice.
Er...very few? A bad programmer will be a bad programmer with a debugger and that bad programmer will be a bad programmer who prints out state after every line of code.
Breakpoints and watches are strictly superior to print statements for understanding the system you're working with. You drop a breakpoint where, as you yourself put it, "the bug is likely to be," you look around, you kill the process and you make a change. It doesn't "create dependency", it's just better at solving the problem. Anyone can fall back to println debugging if necessary. It's not some difficult thing. But it's wasting your time.
If I'm 90% sure I know what the bug is and it's a system where it's easier to add a print than to enter the debugger (yes, those types of systems exist), I'll do that first.
If you've written something in a language where you don't have a debugger...that's your own damned fault. :-P
It's often hard to run a stepping debugger when you have an embedded hardware at hand. It's equally hard to run such a debugger when you have multi-threaded code. And the same stands for virtually any system that works with network directly, where timeouts are plentiful.
Also, good luck with a debugger in this modern architecture of microservices that happens to be hype nowadays.
Totally true. But that's a pretty rare situation.
> It's equally hard to run such a debugger when you have multi-threaded code.
Maybe your experience is different, but Every piece of multi-threaded code I've ever written has fallen into one of two buckets: task-pooled parallelism or interlocking features that shouldn't block one another. The former is trivial; reduce the task pool size to a single thread. The latter is definitely harder, but modern tooling (I'm partial to VS2017's Threads window) makes this a much more achievable thing; you can break across all of them and step between them effectively.
> And the same stands for virtually any system that works with network directly, where timeouts are plentiful.
I find myself debugging in environments where I can control timeouts, but if you can't, yeah, this is totally a problem. Leaving a service paused for ~3-5 minutes while I poke at it doesn't drop connections with my dev configs, though.
> Also, good luck with a debugger in this modern architecture of microservices that happens to be hype nowadays.
"Doctor, it hurts when I do this..."
If you can't effectively stub out an environment around your microservice so that you can run it in a debugger-friendly environment, you don't have a microservice--you have a monolith that communicates over pipes rather than function calls, and that's strictly worse in the first place.
> Totally true. But that's a pretty rare situation.
I know it's rare to work with embedded systems if you don't work with embedded systems. Though when you do work with them, this "rare situation" suddenly becomes prevalent.
>> It's equally hard to run such a debugger when you have multi-threaded code.
> Maybe your experience is different, but Every piece of multi-threaded code I've ever written has fallen into one of two buckets: task-pooled parallelism or interlocking features that shouldn't block one another.
It all works well until it doesn't. That is, until you need two threads to communicate with each other (otherwise, why are they even running in the same process?).
>> And the same stands for virtually any system that works with network directly, where timeouts are plentiful.
> I find myself debugging in environments where I can control timeouts, [...]
All of them? My simplest cases have dozen timeouts one behind the other, at different levels of the stack. Even though I potentially can set them all, it's all very tedious. Not to mention that the timeouts can interact in non-trivial ways, so it's often hard to track all of them.
>> Also, good luck with a debugger in this modern architecture of microservices that happens to be hype nowadays.
> If you can't effectively stub out an environment around your microservice so that you can run it in a debugger-friendly environment, you don't have a microservice
https://en.wikipedia.org/wiki/No_true_Scotsman
Also, I haven't said that "you can't effectively stub out an environment". There are other difficulties around debugging microservices, like mentioned before controlling timeouts everywhere.
I rarely use the step functionality, though, because it just takes too long. More frequently when I hit a breakpoint, I examine the current state, figure out the next place that I am interested in stopping and then add a breakpoint there before resuming.
In these cases, the Feynman method is sometimes all that you can apply. I have already spent plenty of hours with a stacktrace on one screen and the source code on the other screen, stepping through the source code in my mind (usually backwards from the end of the stacktrace).
The caveat obviously being that debugging code written using some JS frameworks, like Polymer, is a nightmare.
PHP and JavaScripy are great for debugging. Even Node is awesome. Rails and mainstream JavaScript frameworks... not so much. Nothing about the languages.... The people who design the frameworks and build tools just don't seem to value it.
https://developer.mozilla.org/en-US/docs/Tools/Debugger/How_...
I wonder how much that has to do with tooling? When programming in python I run everything in a debugger basically all the time. When doing JavaScript front-end work it's back to print debugging.