home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / arch / 8884 < prev    next >
Encoding:
Text File  |  1992-08-13  |  2.0 KB  |  46 lines
  1. Newsgroups: comp.arch
  2. Path: sparky!uunet!uunet.ca!geac!itcyyz!yrloc!rbe
  3. From: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
  4. Subject: Re: Why would you like a debugger (Was: What would you like in a debugger?
  5. Message-ID: <1992Aug13.144226.8391@yrloc.ipsa.reuter.COM>
  6. Reply-To: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
  7. Organization: Snake Island Research Inc, Toronto
  8. References: <19920809.175600.935@almaden.ibm.com> <343@moene.indiv.nluug.nl> <id.8J9S.1P4@ferranti.com>
  9. Date: Thu, 13 Aug 92 14:42:26 GMT
  10. Lines: 34
  11.  
  12. In article <id.8J9S.1P4@ferranti.com> peter@ferranti.com (Peter da Silva) writes:
  13. >In article <343@moene.indiv.nluug.nl> toon@moene.indiv.nluug.nl (Toon Moene) writes:
  14. >> OK, but I only explained why *I* wouldn't use a debugger. Note: here's my  
  15. >> silent assumption: Debuggers are slow: they've a steep learning curve,  
  16. >> load slowly, take their time to reach the breakpoint you think will tell  
  17. >> you what's going wrong (I often watch my colleagues using one - it's so  
  18. >> much fun :-)
  19. >
  20. >What, slower than recompiling the program with appropriate printfs?
  21. >
  22. >I don't use debuggers often, and if I had a fast enough interactive compiler
  23. >I wouldn't use them at all, but they're a hell of a lot faster than "make"
  24. >when you get down to the last bit of troubleshooting.
  25.  
  26.  
  27. Ah, perhaps I'm missing something here, but I personally do NOT like
  28. the idea of modifying ANY code in order to debug it. That is, insertion
  29. of printfs is harmful to maintainability. 
  30.  
  31. It's easy to get in a situation where you THINK you have changed something,
  32. or maybe you haven't, but you went and had coffee, then the phone rang...
  33.  
  34. Granted, the ability to make deltas reduces the potential harm here,
  35. but I MUCH prefer non-intrusive (from the source code modiciation 
  36. standpoint) debuggers.
  37.  
  38.  
  39.  
  40.  
  41. Robert Bernecky      rbe@yrloc.ipsa.reuter.com  bernecky@itrchq.itrc.on.ca 
  42. Snake Island Research Inc  (416) 368-6944   FAX: (416) 360-4694 
  43. 18 Fifth Street, Ward's Island
  44. Toronto, Ontario M5J 2B9 
  45. Canada
  46.