Debuggers = wasteful timesink??
-
"and a few judiciously placed print statements." The day I found out I could debug ASP.NET apps I rejoiced. Print (or
Response.Writein ASP.NET/ASP) statements suck. They get hidden, they get lost, you have to useResponse.Endif you have redirects. And the number of times I and co-workers have left behind embarassing print statements in our code is not funny. Lets not forget that for web-dev a print statement can be misleading. A > for instance does not appear on the page, just in the source. Same goes for character encoding. Looking at in the debug window though and you can see exactly what the var contains. Plus what happens when you print out one var and leave another that you think is unrelated, but turns out to be the key in the bug? With a print statement, you have to put in and re-run the entire test. With a debug, the vars are all there in the little window that saves lives. I agree stepping through line-by-line is often a time waste, but that is why you have breakpoints to get to the point of break-down. regards, Paul Watson Bluegrass South Africa Brian Welsch wrote: "blah blah blah, maybe a potato?" while translating my Afrikaans. Crikey! ain't life grand?Don't you have them controlled by a DEBUG switch that is cleared in the release build ? That way you can switch the statements back on at any time. Elaine :rose: The tigress is here :-D
-
Don't you have them controlled by a DEBUG switch that is cleared in the release build ? That way you can switch the statements back on at any time. Elaine :rose: The tigress is here :-D
-
Debuggers are a wasteful Timesink I couldn't disagree more with this article/statement whatever. I mean talking about real life and productiviy. Unbelievable!! Errr now *you* waste your precious time with that article :-) Gotta work. ______________________________ Java: The living proof Moore's law won't solve all your problems
If you don't know what you're doing yes a debugger will be a timesink. In the world of 'every line of code is perfect everytime' it's a timesink. In the world I live in, where I can't remember every single detail of every line of code I've written but I have an overall view of the code, in a world where I know that 'this' should happen but didn't, so breakpoint there and let's see what really happens so I can match my mental model with the real world, a debugger is invaluable. Rob Manderson http://www.mindprobes.net "I killed him dead cuz he was stepping on my turf, cutting me out of my bling the same way my ho cuts cookies, officer" "Alright then, move along" - Ian Darling, The Lounge, Oct 10 2003
-
Debuggers are a wasteful Timesink I couldn't disagree more with this article/statement whatever. I mean talking about real life and productiviy. Unbelievable!! Errr now *you* waste your precious time with that article :-) Gotta work. ______________________________ Java: The living proof Moore's law won't solve all your problems
the best solution of some developers is self-debugging code just put code into pool and let others to fix it some people simply do not need debugging at all t!
-
Debuggers are a wasteful Timesink I couldn't disagree more with this article/statement whatever. I mean talking about real life and productiviy. Unbelievable!! Errr now *you* waste your precious time with that article :-) Gotta work. ______________________________ Java: The living proof Moore's law won't solve all your problems
This kinda statement always seems to provoke emotion. Personally I never use the||a debugger. I guess it must be pure habit to use other methods. Regardz Colin J Davies
*** WARNING *
This could be addictive
**The minion's version of "Catch :bob: "It's a real shame that people as stupid as you can work out how to use a computer. said by Christian Graus in the Soapbox
-
Debuggers are a wasteful Timesink I couldn't disagree more with this article/statement whatever. I mean talking about real life and productiviy. Unbelievable!! Errr now *you* waste your precious time with that article :-) Gotta work. ______________________________ Java: The living proof Moore's law won't solve all your problems
-
Debuggers are a wasteful Timesink I couldn't disagree more with this article/statement whatever. I mean talking about real life and productiviy. Unbelievable!! Errr now *you* waste your precious time with that article :-) Gotta work. ______________________________ Java: The living proof Moore's law won't solve all your problems
In theory, if you know all of the possible conditions that could occur, and you're doing development test-first, and your tests cover all the possible cases, you don't need a debugger. Either the test fails, or the program works. Alternatively, all you have to do is read and thoroughly understand the source code, you can prove that the code is correct. :laugh: The problem with this idea is that a program listing is a static entity - a running program (a process) is a dynamic one. Out here in the real world, your program has crashed and left you with the 'Unhandled Exception' box (or as John Robbins quotes Chris Sells as saying, "My program went on vacation and all I got was this lousy address.") How do you know what conditions your tests didn't cover? You pull out the debugger and inspect the state of the program. Robbins tries to teach proactive debugging in his book "Debugging Applications" (and the revised edition, "Debugging Applications for Microsoft .NET and Microsoft Windows", to give it the full title). Basically this involves using the debugger to step through the code while testing it, adjust variables, set the instruction pointer on error handling code, inject faults, etc. I find that it helps me to debug while writing the code - a kind of manual in-depth inspection without writing formal test routines. I feel uncomfortable without a debugger, as I had to be this week when testing a mobile device application that needed to talk to a peripheral through the only available port - therefore, I couldn't connect the debugger. Hello,
MessageBoxdebugging. Test suites are useful for repetitive, repeatable regression tests. But they can't tell you when you don't have a suitable test, and they can't tell you what's wrong when a test does fail. -
Debuggers are a wasteful Timesink I couldn't disagree more with this article/statement whatever. I mean talking about real life and productiviy. Unbelievable!! Errr now *you* waste your precious time with that article :-) Gotta work. ______________________________ Java: The living proof Moore's law won't solve all your problems
Well, there are several things going on here in this article that are easy to overlook. First off, the guy lures you into the idea that incredibly powerful tools waste time because they're so hard to learn, having so many features. Good grief. When I debug something, I set a breakpoint and I hover the mouse over a variable to see its contents, and I single step to see the flow. That's about it. Do I use all those other fancy features on a regular basis? Of course not! I choose the features I need to efficiently solve the problem at hand. The second problem with this commentary is more insiduous. TDD merely shifts the time spend in debugging from the back-end to the front-end. Essentially, with TDD, you are "debugging" the code first, then writing it. In my mind, TDD is still debugging, but it uses a different tool--the unit test. This fellow seems to fail to recognize this. If you look at programming as two tasks--writing code and testing code (which includes debugging it), he's still spending the same (and probably more) time debugging. He's just doing it before writing code, rather than after. Finally, using students to examplify the problem with debuggers is like saying jumbo jets are bad because your Cessna pilot can't fly it. They're students for a reason. I remember wasting time with a debugger because my skills at reviewing my own code were untrained. But guess what? The debugger became my training tool, and I began to use it less and less because I understand programming better. [edit] And I failed to mention the biggest problem of all--writing good unit tests is at least as complicated, if not more so, of a skill to learn than operating a feature-laden debugger.[/edit] Marc Latest AAL Article My blog Join my forum!
-
Debuggers are a wasteful Timesink I couldn't disagree more with this article/statement whatever. I mean talking about real life and productiviy. Unbelievable!! Errr now *you* waste your precious time with that article :-) Gotta work. ______________________________ Java: The living proof Moore's law won't solve all your problems
What silliness. I just fixed a handful of bugs that would have taken ages to track down without a debugger (and I was using all sorts of methods to help find them.) Two more bugs were caught by the VS7 debugging options and the debugger took me right to the offending line. But there is an additional advantage of a debugger; simply stepping through the code and observing what it is actually doing. I cannot overstate the benefit of doing this. Not only has this helped me understand my own, or other's, code better, I've found very obscure bugs and/or performance bottlenecks doing this. My own experience is that developers who understand their tools and use them write more solid code than those who don't. Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
"and a few judiciously placed print statements." The day I found out I could debug ASP.NET apps I rejoiced. Print (or
Response.Writein ASP.NET/ASP) statements suck. They get hidden, they get lost, you have to useResponse.Endif you have redirects. And the number of times I and co-workers have left behind embarassing print statements in our code is not funny. Lets not forget that for web-dev a print statement can be misleading. A > for instance does not appear on the page, just in the source. Same goes for character encoding. Looking at in the debug window though and you can see exactly what the var contains. Plus what happens when you print out one var and leave another that you think is unrelated, but turns out to be the key in the bug? With a print statement, you have to put in and re-run the entire test. With a debug, the vars are all there in the little window that saves lives. I agree stepping through line-by-line is often a time waste, but that is why you have breakpoints to get to the point of break-down. regards, Paul Watson Bluegrass South Africa Brian Welsch wrote: "blah blah blah, maybe a potato?" while translating my Afrikaans. Crikey! ain't life grand?Paul Watson wrote: Lets not forget that for web-dev a print statement can be misleading. [..] I agree! Another one: Consider a layered application, where some high level code (main app) calls another module/class, say in a DLL. Each of them gives verbose output to the debug window - You will have problems sorting out which component gave which output, a total mess. Even with a logging API. ______________________________ Java: The living proof Moore's law won't solve all your problems
-
What silliness. I just fixed a handful of bugs that would have taken ages to track down without a debugger (and I was using all sorts of methods to help find them.) Two more bugs were caught by the VS7 debugging options and the debugger took me right to the offending line. But there is an additional advantage of a debugger; simply stepping through the code and observing what it is actually doing. I cannot overstate the benefit of doing this. Not only has this helped me understand my own, or other's, code better, I've found very obscure bugs and/or performance bottlenecks doing this. My own experience is that developers who understand their tools and use them write more solid code than those who don't. Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
Joe Woodbury wrote: What silliness. I just fixed a handful of bugs that would have taken ages to track down without a debugger [..]( - Yeah, its basically a very good thing to get your debugger to that line whre the whole problem starts as soon you press F11. you have the whole thing reproduced to that point. you have the stack trace, the variables, everything. - Or leaks - Consider other peoples code you do not know - you have only .h or .dll and you might have debugging info enabled. Its so important - Some runtimes (java,python) automatically give you stack traces via stdout/stderr but with c++/c you would have to dig for it .. debugger of course solves that problem too ______________________________ Java: The living proof Moore's law won't solve all your problems
-
What a load of crap! Debuggers are one of the most useful development tools. The ability to step through your code, line by line to make sure it is doing what you want it to do, rather than what you thought you told it to do, is one of the greatest assets of modern development. Obviously this guy hasn't written much serious code in his time, otherwise he wouldn't be talking out of his arse like this. I teach a lot of classes in C++, Java, C#, TDD, XP, Patterns, etc Ah, there we go. Teach. Probably not doing a lot of real world development then. with his or her nose buried in a debugger, painstakingly stepping from line to line, examining variables, setting breakpoints, and generally wasting time. The bug they are tracking could be found through simple inspection of the code. Modern development is far too complicated to rely on just looking at the code. The debugger lets you inspect the code and also check the results you are getting. I find this makes finding bugs so much easier, when you can see what's actually going wrong. Michael Blue canary in the outlet by the light switch Who watches over you Make a little birdhouse in your soul - They Might Be Giants
Michael P Butler wrote: Ah, there we go. Teach. Probably not doing a lot of real world development then. As far as I can remember, absolute newbees do not get the point of line-by-line execution by a runtime. If they actually see a debugger tracing through their code and see the value of vars change, something inside their heads makes "click" (basically, this way you just set the troff flag in their brain's status register and off they go ;) ). ______________________________ Java: The living proof Moore's law won't solve all your problems
-
Well, there are several things going on here in this article that are easy to overlook. First off, the guy lures you into the idea that incredibly powerful tools waste time because they're so hard to learn, having so many features. Good grief. When I debug something, I set a breakpoint and I hover the mouse over a variable to see its contents, and I single step to see the flow. That's about it. Do I use all those other fancy features on a regular basis? Of course not! I choose the features I need to efficiently solve the problem at hand. The second problem with this commentary is more insiduous. TDD merely shifts the time spend in debugging from the back-end to the front-end. Essentially, with TDD, you are "debugging" the code first, then writing it. In my mind, TDD is still debugging, but it uses a different tool--the unit test. This fellow seems to fail to recognize this. If you look at programming as two tasks--writing code and testing code (which includes debugging it), he's still spending the same (and probably more) time debugging. He's just doing it before writing code, rather than after. Finally, using students to examplify the problem with debuggers is like saying jumbo jets are bad because your Cessna pilot can't fly it. They're students for a reason. I remember wasting time with a debugger because my skills at reviewing my own code were untrained. But guess what? The debugger became my training tool, and I began to use it less and less because I understand programming better. [edit] And I failed to mention the biggest problem of all--writing good unit tests is at least as complicated, if not more so, of a skill to learn than operating a feature-laden debugger.[/edit] Marc Latest AAL Article My blog Join my forum!
Marc Clifton wrote: First off, the guy lures you into the idea that incredibly powerful tools waste time because they're so hard to learn, having so many features. Right, he even comes along with a software development process (Extreme programming) and compares it with a tool (a debugger). People use a tool for a specific reason. It's just a tool. It does not say anything about programming abilities. In 1989 when i was programmming 68k assembly, you basically had step, step into, run-to-line, print exp, etc.. these commands haven't really changed since then. ______________________________ Java: The living proof Moore's law won't solve all your problems