I use debuggers all the time. Don’t repeat yourself and keep it simple stupid goes a long way. I’d much have something readable and easy to follow than something clever.
Ask HN: Why are we not using debuggers more?
21–30 of 48 posts
Re: Ask HN: Why are we not using debuggers more?
#22In my case, it's a technical limitation: the code that I write runs on a remote computer, not my laptop. I know that "remote debugging" is a thing, but I would need to talk with our network guys about firewall exceptions to allow me to connect to the Kubernetes pod over port XYZ. That sounds like a hassle, and I'm not sure they'd allow it.
Can you SSH into the remote machine? Visual Studio Code offers quite solid remote development tools through ssh (maybe other means too): https://code.visualstudio.com/docs/remote/remote-overview I would guess that it also supports debugging.
That's a really interesting idea! I'm going to try that out later.
(Thanks also to matthias247, who also suggested this.)
Re: Ask HN: Why are we not using debuggers more?
#23I try not to debug code with print statements but the build time w/ vs. w/o the debugger is so much longer that it makes sense for small issues to debug with print statements on occasion.
Re: Ask HN: Why are we not using debuggers more?
#24Earlier quoted context omitted.
There is actually a surprising amount of reverse debugging products out there, some are listed here: http://jakob.engbloms.se/archives/1564 Would you be willing to use one of those?
Nice link. Thanks for sharing. I took a quick glance and saw that most of them are for embedded systems. Apart from gdb, do you know anything more friendly for Unix and C/C++ programs?
There is undo, I would be very interested in your thoughts on it: https://undo.io/
This may also contain further pointers that I missed: https://softwareengineering.stackexchange.com/questions/1815...
Re: Ask HN: Why are we not using debuggers more?
#25I avoid debuggers because if I can't debug something without them, said something is too complicated for me to understand now, let alone in the future. Moreover, if said something is that complicated, it is almost certainly wrong in several subtle ways. One nice property of asserts is that they keep working even when your attention is elsewhere.
How do you step through your code to understand what EXACTLY is happening to the data without a debugger?
Re: Ask HN: Why are we not using debuggers more?
#26Not me. I love debuggers. One of my favorite features of Java has long been the JDWP support for remote debugging. Being able to fire up Eclipse (or whatever) and attach to a running process on another machine and step through the code... amazing. Not sure if other platforms have caught up in that regard or not, but to me for the longest time that single feature was one thing that made Java very cool in my book, compared to a lot of other environments.
Re: Ask HN: Why are we not using debuggers more?
#27I program in Scala and didn't know what IntelliJ debugger could do until someone taught me how to use it (including the nifty trick of setting break points inside 3rd party libs).
Sometimes you don't know what you don't know.
But yeah, these days I rely on the debugger heavily. Even for Python :)
Re: Ask HN: Why are we not using debuggers more?
#28For me debuggers are the first resort. I learned a long time ago that if you get in the habit of hacking the code to debug it (say adding print statements) you will eventually check in debug-related changes that you shouldn't. Using the debugger means you don't have to hack the source code. I use Jetbrains tools and have an easy time debugging in Java, Python and Javascript. In Java I'd say that you can use unit test…
I started out using debuggers because it made sense to step through the execution, then stopped for years as a junior- and mid-level because nobody else did, least of all the toxic lead engineers that were liberally sprinkled over every London agency I worked in, and then eventually turned 40, at which point I instantly stopped giving a shit about what anyone thought of me, and went back to being a totally-non-rock-stroke-ninja coder again. Debugging.
It’s not just Unix culture that’s allergic to debugging, it’s every chancer and charlatan the world over.
Re: Ask HN: Why are we not using debuggers more?
#29I am sadly not using a debugger because the last two or three times I've tried to set up XDebug for PHP, it just hasn't worked. I have 15 years experience with the language. Have tried multiple IDEs, multiple plugins, multiple browser extensions. Have tried multiple ways of running PHP (docker vs. native). I think the last time I might've had XDebug running properly such that I could do debugging in an IDE was probably 2018 or so. It wasn't too long ago that I found the `dd()` command, which is really quite handy and has gotten me by since then.
I'll give it another crack because I have just started a new job (new machine, new PHP, new everything) but I have my doubts it will work this time, either.
Setting up debugging for PHP has got to get a whole lot easier and user-friendly, IMO.
Re: Ask HN: Why are we not using debuggers more?
#30When build times are short, spinning up a debugger is overkill compared to adding a couple of debug statements. The code I write is also a lot more asynchronous nowadays, and debuggers are fairly worthless for async code imo. Pausing on a breakpoint conceals issues with asynchronous timing that good logging will show immediately. I still believe debuggers should be a part of every developers toolkit, but like anythin…
> When build times are short, spinning up a debugger is overkill compared to adding a couple of debug statements.
I often find it a lot faster to set up breakpoints and fire up the debugger than to write debug statements. At least in some IDEs, breakpoints are a single click each, and if you have to restart the application/module/whatever anyway, doing that in a debugger instead of a non-debug run is also just a click. I can then inspect any variable values at the breakpoint instead of having to explicitly include all potentially interesting ones in the debug output.
When I'm trying to figure out a problem in code I'm writing rather than one in production, the debugger is often my first resort.
I'm mostly writing plain old backend code without asynchronicity, though.
Debug output (at a reasonable level) is still useful even outside of asynchronous program flow, of course, because it might give immediate clues for problems encountered in testing or production. If you don't have a good idea of where to look, debug output from several places might also be nicer than having the program stop at lots of breakpoints that turn out to not be useful.