Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What a good debugger can do

werat.dev

Post reply on HN
Print view View original

201–208 of 208 posts

Re: What a good debugger can do

#201

Post by maleldil »

bornfreddy wrote: post #134
justeleblanc wrote: post #118

Earlier quoted context omitted.

Do we know if that person is a freshman student who barely started coding?

There are many other experienced devs (me included) who simply don't see debuggers worth the effort in most cases . There are exceptions and every competent dev should know how to use one, but to me it is like using crutches - I run faster and better without them. I did use debuggers at the beginning though, a lot too. Then I learned to think about problems and to simplify design of the code, making debuggers much le…

I find it useful to run pdb when my program throws an exception. You can run your program with `python -m pdb -cc file.py args`, and it will leave you in a prompt when there's an exception or a breakpoint (eg the `breakpoint` statement). From there, you can evaluate expressions using local variables.

Re: What a good debugger can do

#202

Post by sam_bristow »

MaulingMonkey wrote: post #169
snarfy wrote: post #162

Earlier quoted context omitted.

Calling Visual Studio 'less powerful' than GDB is telling. When you have a bug that doesn't happen until hours into your program execution, being able to set a breakpoint, edit-and-continue, and set-next-statement are worth their weight in gold. You can solve in the moment what would take literally days, even weeks using a logging approach. Sure they both have their place but having a debugger is indispensable, and V…

> edit-and-continue Breaks on enough codebases for me to not be in the habit of relying on it. My own "killer feature" of VS debugging is being able to open up a crash dump, have VS auto-download matching pdbs from a symbol server, and auto-view the correct source file version/revision thanks to source indexing - without checking out by hand and turning my build stale. Killer ergonomics. Sometimes I'll resort to wind…

I've been wanting that symbol server style workflow for GDB for years. It looks like all the parts are there but I haven't found anyone who has plumbed them together into a complete system yet.

Re: What a good debugger can do

#203

Post by crabbone »

turtledragonfly wrote: post #160
crabbone wrote: post #151

Earlier quoted context omitted.

Both interactive and declarative debuggers work better in distributed systems than logging because they can observe events as they happen, and don't need to recreate the order in which they happened from the records which are very hard to make chronologically consistent. Things like EBPF (which may implement sort of a declarative debugger) are, perhaps the only tool you may hope to use in high volume and high frequen…

One thing that can be pretty nice which is kinda neither traditional debugging nor logging is DTrace (or similar). Basically event tracing on steroids. Maybe EBPF is in that vein? I don't have much personal experience with it, but I have heard some stories of good success on busy production systems. I guess my (limited) experiences with distributed systems are different than yours. The notion of "pausing" the system…

> Maybe EBPF is in that vein?

Not just that :) It was "inspired by". Well, it's the same idea.

> The notion of "pausing" the system to step through things interactively was usually untenable.

That's not what EBPF would be used for in such a system. You'd write a bit of code that can be loaded into a running program and executed as a particular condition occurs. Like how you can attach some code to evaluate on a breakpoint in many other debuggers.

Re: What a good debugger can do

#204

Post by cxr »

q845712 wrote: post #89
Jorengarenar wrote: post #47

>When people say “debuggers are useless and using logging and unit-tests is much better,” Who? Who does say that? Freshman students who barely started coding? >I suspect many of them think that debuggers can only put breakpoints on certain lines, step-step-step through the code, and check variable values. That alone provides enough value to know debuggers are useful.

in my experience a large portion of go programmers seem to think this. I would guess (but haven't confirmed) that there's someplace where rob pike and/or russ cox are on the record telling folks that they don't really need debuggers because printf is great.

Rob Pike goes quite a bit further than that—don't even use printf or look at stack traces:

> A year or two after I'd joined the Labs, I was pair programming with Ken Thompson [...] Ken taught me that thinking before debugging is extremely important. If you dive into the bug, you tend to fix the local issue in the code, but if you think about the bug first, how the bug came to be, you often find and correct a higher-level problem in the code that will improve the design and prevent further bugs.¶ I recognize this is largely a matter of style. Some people insist on line-by-line tool-driven debugging for everything. But I now believe that thinking—without looking at the code—is the best debugging tool of all, because it leads to better software.

https://www.informit.com/articles/article.aspx?p=1941206>

Re: What a good debugger can do

#205

Post by turtleyacht »

It would be nice to have event-sourcing and associated tools set up where one could drop into a REPL of some collection of docker-compose'd microservices, and step through a heterogeneous collection of the stack--from HTTP request to db query, and back out again.

Certainly tools like App Dynamics and Datadog enable this app stack tracing, and Docker Compose enables composing services.

To be able to play back transactions backwards and forwards among services would be a dream.

Wondering if any folks have played with this kind of debugging?

Re: What a good debugger can do

#206

Post by AndriyKunitsyn »

carapace wrote: post #175
AndriyKunitsyn wrote: post #9

Earlier quoted context omitted.

That's all good, but if the problem itself operates with more data than a human can reasonably operate with, this no longer applies. I do 3D meshes programming. The amount of vertices, planes and other geometrical entities that I need to operate with in my algorithms is too big for me to do printf debugging. I can't just look on a long list of 3D vertex coordinates and visualize the mesh they make in my head. Moreove…

FWIW it sounds to me like you're using what effectively amounts to fancy 3D printf, eh? In other words logging/printf help "visualize" non-geometrical entities.

Not _only_ that. It was an example of how tools help me deal with inherent complexity that cannot be dealt with by "just write better code".

I do use debugger. During big fixing, I need answers to various questions, such as: on what halfspace does a vertex lie? Is this point inside that polygon? What is the distance between two points? - and so on. If I didn't have a debugger, I'd have to stop the program, find the distinguishing features of the entities I'm interested in again - and this is often the hardest part, since the same code can be called thousands of times with different data - put printfs, rebuild, relaunch and prepare for another cycle. With a debugger, I just put these questions into LLDB queries - and I get answers. It is so much faster.

Would it be possible for me to do my job without all that, using debug prints only? Theoretically, yes. Would it be practical? Absolutely not.

Re: What a good debugger can do

#207

Post by carapace »

AndriyKunitsyn wrote: post #206
carapace wrote: post #175

Earlier quoted context omitted.

FWIW it sounds to me like you're using what effectively amounts to fancy 3D printf, eh? In other words logging/printf help "visualize" non-geometrical entities.

Not _only_ that. It was an example of how tools help me deal with inherent complexity that cannot be dealt with by "just write better code". I do use debugger. During big fixing, I need answers to various questions, such as: on what halfspace does a vertex lie? Is this point inside that polygon? What is the distance between two points? - and so on. If I didn't have a debugger, I'd have to stop the program, find the d…

Meaning no disrespect, and I swear I'm not just being contrary for kicks, but it now sounds (to me) like you want to be using Common Lisp? It sounds like you're fighting your tools with your tools.

Re: What a good debugger can do

#208

Post by AndriyKunitsyn »

carapace wrote: post #207
AndriyKunitsyn wrote: post #206

Earlier quoted context omitted.

Not _only_ that. It was an example of how tools help me deal with inherent complexity that cannot be dealt with by "just write better code". I do use debugger. During big fixing, I need answers to various questions, such as: on what halfspace does a vertex lie? Is this point inside that polygon? What is the distance between two points? - and so on. If I didn't have a debugger, I'd have to stop the program, find the d…

Meaning no disrespect, and I swear I'm not just being contrary for kicks, but it now sounds (to me) like you want to be using Common Lisp? It sounds like you're fighting your tools with your tools.

Why do you think so? I think I'm pretty comfortable with what I'm doing now, but maybe I don't know something.
Post reply on HN