Live data from Hacker News

Ask HN: Why are we not using debuggers more?

news.ycombinator.com

31–40 of 48 posts

Re: Ask HN: Why are we not using debuggers more?

#31
post #15
post #5

I'm getting more into using debuggers lately. They can really help they just take time to learn. As to why they are a last resort. For me it was just having to learn the debugger and also setting up the debugging environment. For every binary needs to be built with debugging symbols and any libraries you're wanting to step through you have to find the symbols for those too. Also I think it depends on how low level th…

Yes, it is sad that setting up debugging is so tedious. Could you give some examples or languages/environments with "bad" debuggers?

Off the top of my head: Multi-threaded C++ is one. Odin lang has poor support for many debugger features.

The Chromium Project can be way too slow to run in a debugger. Even just debugging the Content Shell can be very slow.

Re: Ask HN: Why are we not using debuggers more?

#32
I use debuggers, but only if "prints" don't help me figure out the issue at hand first. Debugging via "prints" works out of the box.

You put a "print" statement dumping whatever data structure you want, you run the program again, and voila you got something. Now, the "where to put the print" is an art on itself of course. If you don't know where to put it, then either you start writing multiple "print"s here and there (following an approach similar to binary search) or you use a debugger and go step by step until you find right place to inspect.

The problem with debuggers is that they do not work out of the box. If you use the terminal, then you have use an external program and read its manual to understand how to debug, how to put breaks. Depending on the platform you are using, you may require even an executable to run the debugger on. Sometimes you don't have an executable. Sometimes you don't know where the "entry" point of your program is, but you know where the bug relies. Some debuggers require you to point the debugger to the entry point.

If you use an IDE like Jetbrains', then for debugging you need as well to do some (minimal) setup as well (the last week I had to debug a Node.js program: it was simple, but it didn't work out of the box. Also, when I open my IDE on a different Node.js repository, my debugging setup was gone).

Re: Ask HN: Why are we not using debuggers more?

#33
The people I've met who don't use debuggers either write very uninteresting code day to day or just get by enough with their old ways of print statements, enough to not feel compelled to learn to set a debugger up. But I think that's dumb, and it's almost always worth understanding how to set up, especially in a large codebase.

Re: Ask HN: Why are we not using debuggers more?

#35
I like debuggers, but I don't always use debuggers. Typically because I can find the problem quicker w/ a puts/print/etc. than the time it takes me to run the debugger.

I also do a lot of web stuff, and if you're running some server process and you're not running the server process through a debugger directly, then you need to find and attach to the server PID, etc., then maybe deal with threads, and it's just a lot of upfront effort when I could just find the issue by throwing a puts/print somewhere or writing a test.

I'm not anti-debugger, I'm just busy and it's easier to put something in my code (which is how I frequently jump into debuggers too, e.g. binding.irb, binding.pry, debugger, byebug, etc.)

the CLI debuggers (gdb, lldb, etc.) are great when I really need them, but they're a pain in the ass to setup with things that are not C or C++, editor integrations sometimes need setup, and using them without setting breakpoints visually is tedious.

Re: Ask HN: Why are we not using debuggers more?

#36
I make an effort to use a debugger first.

Right now I'm writing some stuff which takes over the terminal and works in recursive loops (ncurses roguelike map generator) so print debugging is a hassle. It's actually quicker to use a debugger.

I find that attaching gdb and running "bt" and "info locals" or inspecting variables with "p" is much cleaner than printing, and helps me visualise what the code is doing much better.

This use of a debugger for "little things" is immensely helpful for when I need to use a debugger at work to solve "big things", which are usually remotely and after-the-fact with a core file, so printing isn't even an option there.

Re: Ask HN: Why are we not using debuggers more?

#37
post #10
post #7

Debuggers don't give you enough information when you want more, and too much information when you want less. Learning and effectively using a debugger can require as much cognitive load as programming itself. Given that, using a debugger takes you out of your programming mindset and into debugger mindset. Using prints, asserts, etc. keeps you in programming mindset, so you can find and fix the problem and get back to…

What kind of information would help you to debug? And what kind of information is "too much"? Personally, I think "too much" is when you get a large table of all variables and their values; it is quite hard to locate the one you care about...

Inspect all global variables in gdb. You get every variable defined in a linked library, pages and pages and pages of output with your own program's global's stuffed somewhere in the middle. Useless.

Re: Ask HN: Why are we not using debuggers more?

#39
I use a debugger every day. Delve[0] Go's debugger made me love the process of debugging my code – either attaching the debugger to an existing running process or the feedback loop of debugging the test code until make it passes the test case.

Back in the days when I didn't use one, it was a miserable developer experience. Thanks to Go and his great decision of having unit testing built into their standard now writing tests and debugging them is a joy.

Far are the days of not using a debugger because the programing language of choice didn't treat debuggers/unit testing as a first-class citizen. I could say that now I sleep a lot better thanks to coding my backends on Go and having the confidence that I can go as much depth as I want to fix any bug.

Debugging for me is an automatic action like drinking water when you're thirsty; two clicks (set breakpoint and click the debug button) and I'm back into the debugger, again.

[0]: https://github.com/go-delve/delve

Re: Ask HN: Why are we not using debuggers more?

#40
post #30

When 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 clic…

> 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.

I have the exact opposite opinion. Firing up the debugger is what you do when you no longer know where to look, because you need it to examine the whole program state and have the ability to step through. Writing a console log with output from a variable is the precise "I already know what the problem is, all I'm doing is verifying it" approach.

> 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

A click that spawns a process that takes 10x longer to spin up. Debuggers are slow and heavy.

Post reply on HN