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

Why I use a debugger

blog.pnkfx.org

Post reply on HN
Print view View original

71–80 of 80 posts

Re: Why I use a debugger

#71

Post by Timwi »

genericlogic wrote: post #16
colesantiago wrote: post #2

I thought using debuggers was standard practice in non trivial programs?

I have mentored a number of software developers from just starting their career to a decade+ long career. Nearly every time I open the debugger to help them work through an issue I get 'what is this? Why has no one ever told me about this?'. This is not a judgement, just an observation. I always assumed debuggers were just part of a tool set but it appears (in my experience) many individuals were never taught that it…

I have the same experience, but with even far more basic things than a debugger, such as the Home/End keys on your keyboard, or the search/replace function. Nobody ever bothers to try and see what they do.

Re: Why I use a debugger

#72

Post by gjulianm »

Const-me wrote: post #69
gjulianm wrote: post #64

Earlier quoted context omitted.

> Put a breakpoint early on startup, once hit put a data breakpoint on the part of the state which messed up, reproduce the bug, and there's very high chance debugger will take you to the code which broke the state. Knowing which part of the state messed up is like 90% of the debugging. Most of the time the part of the state you see messed up is like that because another part of the state is also messed up. Given tha…

> it's usually faster to inspect the code manually I’m not sure how usual that is. Sometimes “the code” is too many thousands of lines to inspect. Other times, “the code” is only the machine code but not the source code, inspecting megabytes of disassembly is not fun.

If you're tracking changes to a given state and seeing which other parts of the state affected those changes, you end up inspecting the same spots, whether it's with a debugger or not.

> inspecting megabytes of disassembly is not fun.

Well, of course there you need the debugger and memory watchers. But I think that fits into the "unusual" slot, most people aren't doing that.

Re: Why I use a debugger

#73

Post by [deleted] »

School-Cotton wrote: post #48
morelisp wrote: post #19

Earlier quoted context omitted.

I suspect this will be controversial, but I read TPOP at a young age and I think it still summarizes my overall view. The quote from the article continues: Blind probing with a debugger is not likely to be productive. It is more helpful to use the debugger to discover the state of the program when it fails, then think about how the failure could have happened. Debuggers can be arcane and difficult programs, and espec…

> The goal of most IDEs seems to be first help with a debugger / executing code/tests, second help with writing code We must not be using the same IDEs. To me “IDE functionality” is almost synonymous with “code navigation”: jump to definition, find references, etc., which are purely “code reading” features.

[deleted]

Re: Why I use a debugger

#74

Post by maleldil »

bruce343434 wrote: post #58
morelisp wrote: post #19

Earlier quoted context omitted.

I suspect this will be controversial, but I read TPOP at a young age and I think it still summarizes my overall view. The quote from the article continues: Blind probing with a debugger is not likely to be productive. It is more helpful to use the debugger to discover the state of the program when it fails, then think about how the failure could have happened. Debuggers can be arcane and difficult programs, and espec…

What do you mean by TPOP?

The book mentioned in the post; The Practice of Programming by Kernigham and Pike.

Re: Why I use a debugger

#75

Post by morelisp »

mtVessel wrote: post #62

When I write code that has multiple, interrelated parts, before I ever run it I step through it in the debugger to verify that my logic is correct, I didn't make any off-by-one errors, library calls return what I expect, etc. I especially do this when the code has destructive side-effects (a file gets moved/deleted, a database get updated, whatever), so I can skip over any external actions I don't actually want to oc…

No, if you use a debugger for this your test suite is too slow or otherwise too difficult to run.

Re: Why I use a debugger

#76

Post by ehnto »

bruce343434 wrote: post #57
ehnto wrote: post #8

Earlier quoted context omitted.

Which is strange, because debugging in JS and PHP is almost trivial to setup. Perhaps less so in PHP, but for JS it's right there in the browser for client side code.

For sure not trivial with php

It is pretty easy to locally or remotely debug with xDebug, the docs are pretty straight forward. What makes it difficult I find is when you're trying to use it in weird VMs.

Re: Why I use a debugger

#77

Post by mtVessel »

gjulianm wrote: post #63
mtVessel wrote: post #62

When I write code that has multiple, interrelated parts, before I ever run it I step through it in the debugger to verify that my logic is correct, I didn't make any off-by-one errors, library calls return what I expect, etc. I especially do this when the code has destructive side-effects (a file gets moved/deleted, a database get updated, whatever), so I can skip over any external actions I don't actually want to oc…

> I especially do this when the code has destructive side-effects (a file gets moved/deleted, a database get updated, whatever), so I can skip over any external actions I don't actually want to occur until I'm ready for a full test run. I always wrap these statements in a function/if-statement/similar thing that allows me to run the tool in "dry mode" so changes are not done but just logged. It's pretty useful becaus…

Yes, of course, that's the better approach. But you can quickly get bogged down in a ton of extra parameters/environment vars/config scripts/whatever depending on how granular you want that control to be.

My laziness often precludes me from taking that approach until it's clear that it's warranted (but hopefully before I nuke anything critical).

Re: Why I use a debugger

#79

Post by cosmotic »

mypastself wrote: post #39

In my experience, developers who don’t use a debugger belong to one of two groups: 1.) Older hacker types for whom it was previously unavailable or difficult to set up, so they learned to work (well) without it. 2.) Juniors/fresh grads, who often seem intimidated by it, likely because teachers and online resources didn’t emphasize it sufficiently. I think the first group would benefit from introducing a debugger into…

In my experience, there are two intermediate group:

3.) Folks that are, for whatever reason, satisfied with log statements and can't be bothered to learn something new

4.) TDD die-hards where a debugger is evidence of a failure to follow the TDD manifesto

I'm a huge proponent of debuggers but I've encountered Senior SWEs that are not old-hackers or just-out-of-college.

Re: Why I use a debugger

#80

Post by mkdirp »

charcircuit wrote: post #11
mkdirp wrote: post #3

Earlier quoted context omitted.

You'd think. But I still see discussions in JavaScript and PHP related threads where people swear by adding `console.log`/`var_dump` statements to their code over using the debugger. I've seen quite a few threads on r/php where individuals introduce a newer, supposedly better, library that can be used instead of `var_dump`, and there's always the inevitable "why not use the debugger?" to which many reply "because it'…

Logging has the benefit of not stopping your programs. On what I work on stopping the program is not feasible. It will block all of the clients trying to communicate with it and if you pause for too long the clients will disconnect and this may make the problem hard to reproduce. Additionally it can be difficult to attach a debugger on a remote machine compared to deploying a simple update which mechanisms already ex…

Logging is not debugging/print statements.

You also wouldn't generally be debugging a request from random clients. You'd generally be debugging in your local dev environment.

Post reply on HN