tim@hoptoad.uucp (Tim Maroney) (04/09/90)
There are an awful lot of programming problems posted to this place which seem to show a defective understanding of debugging. People seem to think that they will be able to solve all their problems through deduction, by sitting back and thinking about what might be causing the problem and what might be a way to solve it. This is a good way to solve many problems, but for many others (perhaps most), you need to use an empirical method, to wit: breaking into the debugger, stepping through your code, and seeing where it breaks. (The alternative is to insert probe statements which put out information that allows non-debugger tracing of execution, but this doesn't apply to many problems in obscure environments or inside system code.) Long-timers will notice that I'm giving many fewer answers here than I have in the past. One of the major reasons is that I've reached my limit on people who go to the net for an answer before they'll apply the very simplest local debugger strategies to their problems. You will *have* to do this to become a professional programmer, and it will have to become routine for you. There are too many problems that are tractable only to debugger methods. The net does not exist as a substitute for your use of basic programming techniques. It is rude to post a question to the net which you could answer yourself with a small amount of work sitting in front of your computer. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "As I was walking among the fires of Hell, delighted with the enjoyments of Genius; which to Angels look like torment and insanity. I collected some of their Proverbs..." - Blake, "The Marriage of Heaven and Hell"
pratt@boulder.Colorado.EDU (Jonathan Pratt) (04/09/90)
In article <11051@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes: [Complains about people posting problems without working hard enough on them first.] >Long-timers will notice that I'm giving many fewer answers here than I >have in the past. Long-timers also remember that you once came frothing to the net about a 'bug' in Lightspeed C. It turned out you had simply dereferenced a handle while moving memory, and if you'd read the Memory Manager chapter in Inside Mac you would have seen an explicit warning about the mistake you made. This is not not say that I completely disagree with your mini-flame, but I hope you'll acknowledge that problems are often hard to spot when you're too close to them. In sum, it's not surprising that people post their programming woes. A few words from an expert probably saves them hours and hours, and they only have to endure a few insults to get the advice. Jonathan /* Jonathan Pratt Internet: pratt@boulder.colorado.edu * * Campus Box 525 uucp: ..!{ncar|nbires}!boulder!pratt * * University of Colorado * * Boulder, CO 80309 Phone: (303) 492-4293 */
bhil@ohs.UUCP (Brian T. Hill) (04/11/90)
From article <19428@boulder.Colorado.EDU>, by pratt@boulder.Colorado.EDU (Jonathan Pratt): > In article <11051@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes: > > [Complains about people posting problems without working hard enough > on them first.] > [Reminder that even the best miss an obvious problem now and then.] > that people post their programming woes. A few words from an expert > probably saves them hours and hours, and they only have to endure a > few insults to get the advice. > Those few words are indeed precious, but more precious sometimes is the knowledge gained from finding one's own solution. Many times I've put the debugger to the test. Often these sessions are long and tedious, but I've learned much from them. Sometimes, the debugger doesn't help and I resort to older techniques of writing things to the screen at critical moments during program execution. Little by little, I track down the source of my problem and fix it. Certainly I could ask the experts, who would have known right away what I had done wrong, but I wouldn't have learned as much about the problem and other problems alike. An expert is a great thing, but they don't just happen; they come from long hours in the debugger, I'm sure. I agree with Tim Maroney: Before coming here for help, give the problem some thought. More than that, though, give it some work. It's incredible how often "perfect" code doesn't work. I've seen it before: code that is theoretically flawless that does everything wrong. Brian T. Hill bhil@ohs.uucp ohs!bhil@uunet.uu.net
tim@hoptoad.uucp (Tim Maroney) (04/13/90)
In article <530@ohs.UUCP> bhil@ohs.UUCP (Brian T. Hill) writes: >Those few words are indeed precious, but more precious sometimes is the >knowledge gained from finding one's own solution. Many times I've put >the debugger to the test. Often these sessions are long and tedious, >but I've learned much from them. Sometimes, the debugger doesn't help >and I resort to older techniques of writing things to the screen at >critical moments during program execution. Little by little, I track >down the source of my problem and fix it. Certainly I could ask the >experts, who would have known right away what I had done wrong, but I >wouldn't have learned as much about the problem and other problems alike. Very true! The flip side is that by answering other's questions, frequently one's research teaches one a great number of things which one (or two, for schizoids, or more for cluster minds) wouldn't have known otherwise. Unfortunately, answering questions which people could have solved for themselves with an hour in the debugger rarely is useful in this way. It is the student's duty to facilitate the teacher's learning, as well as the more widely known vice-versa. >An expert is a great thing, but they don't just happen; they come from >long hours in the debugger, I'm sure. I agree with Tim Maroney: Before >coming here for help, give the problem some thought. More than that, >though, give it some work. Yep. And if you have done some work, be sure to tell us some relevant information so we'll know that you did sit with the debugger first. Try to give it straight, not filtered; remember, you may be drawing wrong conclusions from the debugger information if you can't solve your problem. It doesn't do any good to jump to the conclusion that (as a purely hypothetical example) the window list doesn't always terminate in a null if, in fact, the window list *does* always terminate in a null and you've just misread things; tell us what you saw. >It's incredible how often "perfect" code >doesn't work. I've seen it before: code that is theoretically flawless >that does everything wrong. Truer words were never spoken. This is why you simply can't program seriously without using a debugger as a matter of course. Looking at source code is just not enough. And one more thing -- if someone *does* give you the answer, why not thank them in e-mail? Most people are pretty good about this, but a few will just take your answer and use it without feeling any of the normal human social obligations of gratitude. This is annoying, and it makes it less likely that the answerer will bother in the future. (Incidentally, I recommend ignoring Pratt's mean-spirited and irrelevant rehashing of an old mistake of mine, a rehashing which had nothing to do with debugger techniques. Everyone here makes mistakes, even Larry and Keith. Pratt seems to have some personal vendetta against me, and I'm sorry that he keeps unleashing it here.) -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "In science it often happens that scientists say, 'You know that's a really good argument; my position is mistaken,' and then they actually change their minds and you never hear that old view from them again. They really do it. It doesn't happen as often as it should, because scientists are human and change is sometimes painful. But it happens every day. I cannot recall the last time something like that happened in politics or religion." -- Carl Sagan, 1987 CSICOP keynote address