|
Are Debuggers Wasteful Timesinks? Martin thinks so
http://www.artima.com/weblogs/viewpost.jsp?thread=23476
This is something I've often felt, but was never sure about because it seemed so contrarian to the "common" view. What do you guys think? People scoff at good ol' print statements, but they've always done wonders for me and are often faster than using debuggers.
I guess the lesson as always is dogmatism is bad...generally.
Crimson
Friday, December 5, 2003
Couldn't disagree more. I was going to suggest the debugger as the single greatest innovation in the "axe and knife" thread.
Brian
Friday, December 5, 2003
Linus Torvalds also thinks debuggers are evil. Patches exist to add kernel debuggers into the Linux kernel, but Linus refuses to merge them into his official tree. He actively discourages their use.
The general idea is that if you need a debugger to stare at memory dumps and thread stacks, then your code is too complicated and should be rewritten.
runtime
Friday, December 5, 2003
runtime:
You weren't kidding. Linus's view on debuggers make Martin's seem downright charitable.
http://seclists.org/linux-kernel/2000/Sep/1177.html
Crimson
Friday, December 5, 2003
One of the big advantages of debuggers over printing is you don't have to recompile every time you find out you need some new information.
If you don't want to use a debugger that's your choice, but I don't see how you can claim they are wasteful timesinks if they help you track down bugs faster. For some uses printing an extensive log is clearly superior to a debugger, but in most cases I just can't see printing being actually better... at best it is equal in productivity
Good debuggers (ie, not gdb... if this is your only experience with a debugger, you can't really speak with any authority) also provide a myriad of tools for helping to understand code, navigate code, and other tasks that are not necessarily directly related to tracking down a bug.
Mike McNertney
Friday, December 5, 2003
In our company, debuggers are not allowed. Debuggers are to controlled development what gotos are to structured programming or what informal testing is to automated unit testing.
Alright, one can find bugs with a debugger, but there are much better methods. Let me reiterate the claim by a previous poster that debuggers should not be necessary for well-written, well-structured code.
But , there is a very fundamental problem with debuggers. They make the debugging activity non-repeatable. Effectively, one is comparing perceived programming behaviour with a /mental/ model. What is the programmer leaves the organisation, or is away from the code for more than a few weeks/days, hours.
If the programmer is able to reason about the expected state of the execution at some point in the code, then he should add an assertion. No excuse possible.
Debuggers are absolute evil. I have never used one and my code is rock-solid.
I should start my own web log about this and similar practices that we use....
Karel Thönissen
Friday, December 5, 2003
Linus's context is very different from many others. Good pro-debugger arguments come from the perspective that you're going through some guy's code who probably didn't use good engineering. But Linus controls his project. So Linus's view applies to just a special case of the debate.
I didn't like the debate on the guy's weblog, because it's a large enough subject that there are multiple cases where you have to decide if it's appropriate to use a debugger.
Tayssir John Gabbour
Friday, December 5, 2003
I do most of my daily work in a platform with a debugger. Sometimes, I wish I had a debugger -- I've literally spent hours trying to find a subtle bug somewhere. But I'll be the first to admit that the subtle bug was due to way over complicated code!
Almost Anonymous
Friday, December 5, 2003
I find that my need for an interactive debugger has dropped quite a bit in these OO-happy days (compared to, say, when I was writing in C). But you'd have to take it away from me by prying it from my cold, dead fingers. It is way too useful a tool in some situations to go without it.
The author's views sorta remind me of the luddite "write with a typewritter, not a word processor" folk; who are probably a lot like the "write with a pen; not a typewritter" folk before them (though I'm just guessing; wasn't around back then).
Mr. Fancypants
Friday, December 5, 2003
Sorry for the quick extra post, but I forgot to mention that I find it weird that he wouldn't at least see the usefulness in debuggers for his students -- isn't it a *good* thing that they are stepping through the code line by line? Peeking under the hood, as it were?
Mr. Fancypants
Friday, December 5, 2003
Maybe different people work better in different ways?
Philo
Friday, December 5, 2003
I agree with Karel's point. Using a debugger is good _for you_.
The fix you make with the debugger, if you are someone who _hasn't gone through the debug process_, is not good. It is easy to come up with a lot of hack fixes, instead of restructuring the code to properly solve the problem.
Multiply this type of fix by the team spending 50% of their time in debuggers, and you can see why so many codebases are a total mess.
But of course, I wouldn't take an extreme view... to ship a product, you do NEED debuggers. However, it would be advisable to somehow limit their use during development.
Roose
Friday, December 5, 2003
A debugger is invaluable when you don't know what code is going to do. Not necessarily because it's complicated, but sometimes you don't know what the result of a function is going to be with particular arguments (documentation is never perfect!)
So you can build a seperate little program to call that function and print the results. Or you can add print statements to your big program (and wait for the recompile). Or you can spend a couple of seconds putting a break point in and running to it to see what happens.
Debuggers, if used properly, are a time saver. Of course if you use them for absolutely everything you're sometimes going to waste time. That they can be misused is no excuse for throwing them away altogether.
Sum Dum Gai
Friday, December 5, 2003
Philo: it's true, but these people have to work together, so it is definitely a valid to discuss whether you should use a debugger or not, or in what cases, etc.
If you are a 1-man team, then of course you can do whatever you want.
Roose
Friday, December 5, 2003
These guys are obviously trying to stir up some controversy. Debuggers are not evil, they are a tool.
A more reasonable explanation might be to say that debuggers are powerful tools, but should not be a crutch that replaces the developer's understanding of the code.
Richard Kuo
Friday, December 5, 2003
I think "debuggers are evil" is a koan. It gives you something to think about, but the statement itself borders on nonsense :)
Insert half smiley here.
Friday, December 5, 2003
Roose - also what music you should listen to while coding and what font you should have in your editor.
So long as a debugger doesn't *change* the code, who cares whether a dev uses it or not? How does it affect the ability of the team to work together?
Philo
Philo
Friday, December 5, 2003
Debuggers are a great tool when trying to understand somone else's code. Single-stepping through with different sets of inputs when trying to understand something poorly documented - or not at all is very enlightening.
However, I don't remember the last time I've found a bug with a debugger. Hmmm.
hoser
Friday, December 5, 2003
I found a null pointer dereference with a debugger a couple of months ago.
Insert half smiley here.
Friday, December 5, 2003
I hate it when some donkey make a ridiculously broad statement about some facet or programming, and all the useless 'haxors' that fancy themselves me too-ing all over the place.
If you're wasting time using a debugger, maybe you're using it innappropriately? Maybe you should use a different means of identifying a bug for that particular case? It all depends on the circumstance. IMO, a debugger is a good way of getting to the absolute heart of a problem in a way logging never can.
Personally, I find it difficult to take anyone seriously that doesn't know how to use a debugger effectively. I suspect most detractors just never learned how to use the tool properly in the first place.
bleh
Friday, December 5, 2003
bleh, agreed.
If one is a strawman randomly stumbling through code with a debugger cluelessly looking for bugs with no idea what he is looking for, then yes, that is a poor use of debuggers (the Martin guy gave something like this as an example). But I say that anyone doing that with a debugger would be just as clueless without a debugger. Let them have printfs and they'd randomly stick them all over the program. None of this has to do with debuggers or printfs, but with a certain hypothetical group of poor programmers who don't know how to debug.
Here's a typical debugger case for me. I don't go stepping through the code. I have a bug report and from looking at it, I know exactly what function is causing the problem. I open up the debugger and set a break on that function. I then execute the program and reproduce the bug behavior, which breaks on that function. I look at the arguments to that function on up the call stack and see where things went awry. Takes but a few seconds and there is zero stepping through code -- the debugger has automatically provided me with the call stack at the time the bug occurs. I could look up the call stack manually, but it would take three minutes. With the debugger it takes fifteen seconds. Time is saved and there has been no loss of understanding.
Dennis Atkins
Friday, December 5, 2003
Philo:
"So long as a debugger doesn't *change* the code, who cares whether a dev uses it or not? How does it affect the ability of the team to work together?"
The claim is that it does change the code. Haven't you guys ever seen code that "looks like" it was written with about 20 iterations through a debugger? I find it hard to believe you haven't. Maybe it depends on the language... at least in C I notice this a lot. C debuggers tend to be very powerful nowadays.
You have a lot of extra insight because you can browse memory all over the place, modify memory, skip over statements, etc. There is no way you could do what you can do with a debugger by stepping through code in your head, no matter who you are.
Now, I am not one against extra insight. The problem, though, is that it makes your code hard to read. You can no longer understand the code just by _reading_ it or doing some basic test runs, but rather you have to now step through it in a debugger to figure out how it works. And every person who looks at it does, which makes the code a time sink.
Dennis:
"If one is a strawman randomly stumbling through code with a debugger cluelessly looking for bugs with no idea what he is looking "
I don't think it is really a strawman. What percent of the time do you spend writing code in your editor vs. debugging? Maybe you guys do it fine, and you're good programmers. The claim is that many or most people are not. Where I work it is probably about 50/50 ratio, which is way too high. A more realistic ratio would be 80/20 or 90/10.
Roose
Saturday, December 6, 2003
I've never measured it but I definitely spend less time poking through the debugger than just about any other activities. A typical coding session for me is to create some big new feature through some sort of process described by hand waving, then use the compiler as a crutch to find all the spelling errors, which I correct. I then run the code, it passes the test harnesses. Then move the new feature to QA if one is available (maybe its me) for more indepth testing and I move on to the next feature. Maybe one time out of five there is some sort of bug, which 9/10 times I locate without debugger or editor -- I just know where the bug is since I've seen everything that can go wrong so many times (and also I use lots of live asserts which always catch when some assumpition is violated by new code months or years after the original code with the assert was been fire tested). Then for the remaining errors, I'll go for a walk or do some cleaning and think about the design until the likely location of the error occurs to me. This is right half the time. Somewhere among all this a debugger might be fired up to finalize what is going on.
Poking through a debugger for hours on end without a clue happens about once a year, when there is some freaky undescribed API behavior that just needs to be carefully observed at a low level.
Dennis Atkins
Saturday, December 6, 2003
Wait a minute Roose, so in your experience in industry, you are seeing folks who are just sitting there for 4 hours a day running code through the debugger?
Yeah, I'm against that! That's just a waste of time. What is going on with them?
It's nothing to do with debuggers though.
Your comment on debuggers affecting structure is interesting. What I find is that any beginning design I have is usually poor but that over time, it magically gets refactored into some elegant underlying pattern that I never even imagined -- it just sort of happens. Make this a little simpler, reduce some arguments there and to ueries instead. Soon, the whole code restructures itself without even needing a master plan.
It does start out impossible to understand but over time becomes much easier to maintain, which is necessary because if you don't attack the complexity at ever higher levels of the pyramid, it will collapse in a heap of rubble.
Dennis Atkins
Saturday, December 6, 2003
To refactor my statement, i'd say that code rot due to lack of refactoring causes the complexity you are observing and not the debuggers themselves.
Maybe for some people having a debugger enables them to put off refactoring a little longer. Not a good trade off there though.
Dennis Atkins
Saturday, December 6, 2003
The problem is not with the debugger itself, it is with the need for a debugger in the first place.
Having a great need for a debugger indicates that the code complexity has reeled out of control, and/or that the programmers lack the focus or experience to actually understand the code, so they just keep hacking the code and running it with the debugger until it appears to work right.
I do use a debugger, but only as a once-in-a-blue-moon last resort.
T. Norman
Saturday, December 6, 2003
I would not use a molecular screwdriver to put together an IKEA Billy Bookcase.
Similarly I would not use an allen key to build a house (not unless it was a very small house and I didn't mind it going all loose after three months).
Sometimes debuggers are the only way to find a bug relatively quickly, there are other tools that can be used along side them, even the print statement (or some wizzy UI equivalent ).
If the language you're using is so abstracted that a debugger would simply confuse and change the process so much as to make it opaque then its likely the debugger won't help you.
Those who've written C and assembler apps know the scenario where it works if you run it under the debugger and crashes and burns if you don't. And that always tends to suggest there's some stack crapping going on.
As for kernel debuggers, apart from the heisenbug side effects you don't really want debugger traps in production kernels for security sake as much as anything else (like performance).
Using a debugger is wasteful only if it doesn't get you to diagnose and fix the problem in a timely manner. Not using a debugger in the right circumstances is just as bad.
Simon Lucy
Saturday, December 6, 2003
I the article's point is more that heavy reliance on debuggers makes them become like a crutch which is a substitute for properly understanding the code, and that leads to time being wasted in other ways.
Heavy dependence on the debugger causes the programmer to judge the code's correctness based on how it goes through the debugger instead of actually understanding the logic. When the debugger says it works, they think they are done, but their failure to actually understand the code means there may be several bugs still left which weren't tested by the combinations that ran through the debugger.
T. Norman
Saturday, December 6, 2003
Wow - I really didn't think that so many people still thought this way...
Sure, people who wander around code in a debugger without trying to understand the code itself are wasting their time, but I'd that doesn't mean that it's the general case. I fail to see how printf's can be quicker or more efficient than examining context in a debugger. Typically when I'm using printf statements for debugging (generally because the quality of the debuggers available for that platform is so bad) I find that I think I need some state information, so I add some print statements (generally more than I think I'll need), recompile and re-test... then realise that I need more info, so the cycle repeats. In a debugger there is a much quicker turnaround.
Also, print statements are fine for simple bugs in a single threaded process, but how on earth do you use them to track down errors like a method call on an object with a corrupt v-table because it has been released too early - in a debugger you can see very quickly that the call stack follows an unexpected route but even with a quite comprehensive logging system that can be much harder to spot. That's just one example where debuggers are a massive help - what about problems like stack overflows, memory corruption, threading issues etc where any (even slight) change to the code can change or even mask the issue completely.
(As an aside - I wonder how many of the people that don't like debuggers also said that they didn't like exceptions in that recent thread - one of my favourite things about debuggers is that they make it very easy to break at, and examine the context around, an area of code that is throwing an exception - without a debugger it's probably easier to know about the area where the exception was caught, which isn't always as useful. If exceptions are being used properly then you know that if your debugger ever breaks in on an exception, something has gone wrong.)
r1ch
Saturday, December 6, 2003
"I fail to see how printf's can be quicker or more efficient than examining context in a debugger."
The main comparison is with debuggers vs. understanding of the code, not debuggers vs. printf.
Understand the code, and you will seldom need a debugger. And if you use printf, it will be only in a few strategic places.
Think about it this way ... suppose a debugger doesn't exist for your language or platform? Would you be helpless, or would you be prompted to read the code thoroughly?
T. Norman
Saturday, December 6, 2003
Sorry - I should have been more specific - I'd just read the article author's comments in the comments section of his weblog he said - 'My real beef is with depending on debuggers to debug code that could 1) be debugged more easily through inspection and 2) be debugged more easily using print statements.'
I quite often work on platforms where the debuggers are so unreliable that they're not worth bothering with (AIX for example), but I think to fix a problem properly you need to understand the code regardless of whether a debugger is available or not - I just find that it's far quicker to pin a problem down using a debugger.
r1ch
Saturday, December 6, 2003
"fix a problem properly..."
*Properly* is the relevant word here. For people who overly depend on debuggers, fixing is the process of repeatedly changing sections of code until the debugger shows that the program runs as expected. They haven't fixed it *properly*, they've just fixed the cases that were shown in their debug run and may have created other problems that will manifest themselves another day.
T. Norman
Saturday, December 6, 2003
The anti-debugger folks make it seem as if the debugger just goes in and fixes all the bugs for you, which as we all know is just bullcrap. You still have to understand the code to fix it and make it run; whether that understanding comes from a debug session or running the code 'in your head' or whatever other method is irrelevant and I'd never work for anyone who tried to dictate such a stupid thing as not allowing developers to use debuggers...
Mister Fancypants
Saturday, December 6, 2003
Some people use the debugger to fix code without really understanding it. Literally, I've seen people do things like "let me increment this variable here and watch what happens." Eventually they get it to work through trial and error ... for now.
Yes, they need at least a PARTIAL understanding of the code to get it to work in some form. But the full and proper understanding is not there, and the debugger is used to cover up the gaps in their understanding.
Debuggers are useful, but depending on them in day-to-day programming hinders a proper understanding of the code.
T. Norman
Saturday, December 6, 2003
Well if people use debuggers to suck and see and prod the code to see what behaviour it has (and they have full knowledge of the code and aren't reverse engineering it), then I'd say they were at fault and not the debugger.
That has precious little to say about debuggers and their use though.
Simon Lucy
Saturday, December 6, 2003
I find all the comments above amazing. Why don't you actually *read* the half-page blog entry linked above instead of commenting on the headline and what you perceive to be the topic?! Or is it that you read the entry, but you glossed over the phrase "Test-Driven Development" as unfamiliar, which would be just as damning for a programmer?
Martin is just saying that for good programmers who write good automated unit tests for all their code, debuggers have become almost obsolete. Most (probably all) bugs you could find with a debugger will have been revealed by your unit tests, during every build, before you even run your program for the first time. Those few bugs that sneak through due to shabby test coverage tend to be easy to spot with a glance at the code.
Flabbergasted
Saturday, December 6, 2003
I bet there's a strong correlation between the anti-debugger camp and people who don't use IDEs. When all you have is gdb, then yes, that kind of debugger doesn't add much value over printf statements and code inspections. But a good integrated IDE debugger like Eclipse or Visual Studio, *will* help solve bugs faster than mere code inspections, period.
Anon. Coward
Saturday, December 6, 2003
Yes, when there is a problem a debugger probably does help find the cause faster. But if you use code inspection first and foremost, preceded by well-organized code, you'll be better able to understand the code as a whole, make modifications more quickly, and prevent other bugs from occuring.
T. Norman
Saturday, December 6, 2003
> quickly found through inspection and a few judiciously placed print statements
I agree. I recently wrote a protocol converter: I log all input and output messages, all internal state changes, and all error messages. Given all these log messages, it's quick and easy when reading the source code to know the code path that was executed in the processing of a given message. A disadvantage of using a debugger is that it's no good for debugging errors that happened when you were not running under a debugger (for example, an error on a QA or customer machine). The one time a debugger is a real tme-saver is when analysing a crash dump or core file.
Christopher Wells
Saturday, December 6, 2003
I happen to use debuggers while debugging, but even if you don't like that, debuggers are a real time saver when testing too.
Need to make sure that your code can handle a rare error in foo module correctly? Just break in with a debugger and write over the return value from a function call and let it go again. Much faster than actually trying to cause that rare error...
Debuggers are also handy when analyzing memory dumps from crashes that happen at customer sites, etc, etc....
Michael Kale
Saturday, December 6, 2003
It honestly looks to me like another case of baby/bathwater:
"Many people don't use debuggers right, so we should get rid of debuggers."
FWIW, that indicates an exceptionally poor grasp of logic, and an inflated sense of self-importance. Sounds like a definite "no hire" [grin]
"The claim is that it does change the code. Haven't you guys ever seen code that "looks like" it was written with about 20 iterations through a debugger?"
Yet another "someone used a debugger to write crap code, so it must be the debugger's fault"
When I crank up a debugger, as someone else mentioned, I've identified where the problem is and set breakpoints - I'm just trying to figure out exactly what's going on. And when I find the problem, I only "patch" it if a patch is appropriate (boundary case, for example). Often it prompts minor (or in a few cases, major) refactoring.
Philo
Philo
Saturday, December 6, 2003
Doctors shouldn't use MRIs or xrays either. Just look at
the person and poke them a little.
son of parnas
Saturday, December 6, 2003
Ummm... The real point to the article is found in the top right-hand corner of the blog page.
Russell Thackston
Saturday, December 6, 2003
I'm not sure about you guys...
But since I've started using nUnit, I've stopped using debuggers more and more. An earlier chap had a great point - do things that are repeatable.
If you spend 5% of your time in the debugger, spend 95% of your time writing the unit test so you don't have to be there next time.
Rick Watson
Saturday, December 6, 2003
<<<It honestly looks to me like another case of baby/bathwater:
"Many people don't use debuggers right, so we should get rid of debuggers."
FWIW, that indicates an exceptionally poor grasp of logic, and an inflated sense of self-importance. Sounds like a definite "no hire" [grin]">>>
I would say this indicates an inability to read -- also a definite "no hire".
Neither I, nor Martin, or Torvalds said anything about getting rid of debuggers. Torvalds says he doesn't include it in the distribution to discourage their use. In fact I said you NEED a debugger to ship a product.
We are saying that people use debuggers too much. If you're talking about knocking down strawman on our side, then why don't you refute the real argument, instead of mocking a contrived extremist one.
Also, as for boundary cases -- that is precisely where you shouldn't use a debugger. In most cases, it is easy to identify the boundary cases a priori, and you can take care of them while you're coding. Not "code for the common case" and use the debugger to fix the boundary cases. I am not accusing you of doing that, but if you have never met anyone who does, then you probably have no programmed with many other people.
Let it be known that I use a debugger every day. I have to because of the codebase I work on. That is why I am against their abuse.
Roose
Saturday, December 6, 2003
Dennis:
"Wait a minute Roose, so in your experience in industry, you are seeing folks who are just sitting there for 4 hours a day running code through the debugger?"
Well, I said the ratio between writing code and debugging. You don't code all day -- you read JOS, you have meetings, talk with coworkers, etc. : ) But yes, I would say the ratio can be 50/50 -- especially because at the end of the cycle, before ship, we spend essentially all day in the debugger to find bugs.
The problem is not necessarily that each individual programmer is stupid, or relies on a debugger. The problem is basically with a large team of programmers --communication and planning. If I am developing the high-level code, and you're developing the low-level code, then you need to give a solid API in order for me to avoid stepping through your code in a debugger all the time to figure out where my assumptions are wrong. As many others have mentioned here, you should provide an automated test which unequivocally defines what your code does and verifies it.
"To refactor my statement, i'd say that code rot due to lack of refactoring causes the complexity you are observing and not the debuggers themselves."
That's fair, and I can accept that. Note that refactoring also requires unit tests. The debugger is a crutch to avoid writing unit tests, and so thus it prevents refactoring.
Roose
Saturday, December 6, 2003
"Doctors shouldn't use MRIs or xrays either. Just look at
the person and poke them a little."
Actually, that's sort of the point. They should know enough about the human body, and know how to examine you and ask questions so that they don't send you for an MRI or X-Ray when your problem could have been solved with a simple procedure or prescription, or diagnosed with a more appopriate tool.
T. Norman
Saturday, December 6, 2003
T. Norman - I'm gonna start calling you "Luka"
(ER reference)
Philo
Philo
Saturday, December 6, 2003
T, please don't be my doctor. I would like someone
who can exercise judgement. Someone who can say
these are my tools and here are the best times to
use them. Your kind of doctoring could end up killing
me.
son of parnas
Saturday, December 6, 2003
So I take it you would prefer your doctor to send you for an X-Ray or MRI even when the problem would be more effectively solved or diagnosed otherwise?
You are missing the point but you are agreeing with me. I am exactly saying that the doctor should know the appropriate time when to use and NOT use each tool, and should not rely on one popular tool as a crutch to cover up gaps in their understanding.
T. Norman
Saturday, December 6, 2003
Well, unit tests are good, but what happens when your unit needs to be integrated with someone elses unit? (in a non-sexual way).
Last time I ran Linux it dumped core all over the place. Maybe Linus *should* be using a debugger.
Jorel on Software
Saturday, December 6, 2003
>So I take it you would prefer your doctor to send you for an >X-Ray or MRI even when the problem would be more >effectively solved or diagnosed otherwise?
I would expect my doctor to have the experience
and judgement to pick the right strategy. I would
not expect absolute simple minded statements, like
all disease can be cured with deep tissue massage,
when there are clearly times when an MRI is necessary.
son of parnas
Saturday, December 6, 2003
I am also very solidly in the "no debuggers" camp.
I just recently started a new contract and 2 incidents reinforced my point of view:
1. Coworker and I were adding a feature, he using a debugger, I relying on log statements and understanding the code (this is "instant legacy" code -- no unit tests). He kept seeing a persistent error that I wasn't seeing. Finally he ran it without the debugger, and the phantom problem disappeared -- the cause was a bug in the debugger.
2. Same coworker and I tracking down a bug. It's not clear why it's happening, so we pair program for a while. At his cube, we step through the same code, repetition after weary repetition. After 20 minutes, I have a brainstorm and go look at the code base. Sure enough, a critical file hasn't been updated. We update it, and all is well.
I don't object to *any* technique that I can think of that's used with intelligence and vigor, and I know some people do use debuggers that way: as tools, not crutches. But I've seen many, many cases like the ones above, and so I prefer unit tests, assertions, logging and *thinking* to debugger tedium.
Portabella
Sunday, December 7, 2003
A few years ago we decided to design and implement a debugging class into all of our applications. It would do all the neat stuff like write logs, etc all the things that a debugger is meant to do. However we discovered that on 40% of the times that our software broke it was caused by the debugger! Typically trying to write to a log file on a server that had dropped out, or trying to use a COM component that was non existent, etc. We dumped it in the end and life was easier. I still think debuggers are useful but as far as I'm concerned they need to be kept extremely simple.
Realist
Sunday, December 7, 2003
Realist, if you can't write a logging subsystem there's
not much hope for anything else :-)
son of parnas
Sunday, December 7, 2003
Try writing an emulator for the Sega Saturn video game console machine and then come back to talk to me about debuggers. Emulating complex hardware separates the men from the Linuses.
Whatever
Sunday, December 7, 2003
Son of Parnas,
Actually the logging subsystem (as you call it) was a mere fraction of the debugger functionality.
You passive aggressive geek types make me laugh :-)
Realist
Monday, December 8, 2003
Funny how a smiley kind of magically makes a sentence non-offensive.
Like "I hope you get cancer in your ass :-)"
Whatever
Monday, December 8, 2003
Has anyone else ever caught themselves doing this:
"Hmm..Lemme just try this and run the debugger.
Nope..didn't work. Ok, lets just quickly try this one..
No...this one??
"Hey..cool..it worked."
I'll admit, I've caught myself doing "mindless programming" a few times by just trying different things and using the debugger as a crutch. Virtually everytime, the reason is I'm tired not wanting to actually *think* about what I'm doing.
In cases like this, the debugger is being improperly used. As someone had said, had I bothered to think my code through, or had better unit tests coverage then I would have been able to easily spot the problem.
So I would agree that in many cases, a debugger should not be necessary. Good design and unit tests will quickly highlight the bugs.
On the other hand, dogmatic chants such as "Debuggers are evil" are just plain stupid. Debugging other people's poorly written code can be a good reason for using a debugger.
Mark Hoffman
Monday, December 8, 2003
Debugger use should be like abortions - safe, legal, and rare. :D
On a more serious note, it's a tradeoff. Debuggers let you fix the bugs you do have, but they also let you get sloppy. Who needs code review - I'll just debug it when it crashes!
Jason McCullough
Tuesday, December 9, 2003
 Recent Topics
Fog Creek Home
| 
