(cc'd to CS Mailing List where I think it might be more apropriate) On Thu, 17 Jan 2002 at 22:43, fooler wrote: > well i dont really understand what your are talking right now and im > confuse... what i understand is that, debugging is to search for and > eliminate malfunctioning elements or errors in computer program.
I think DocMana was pointing out that the more popular "debug by trial and error" is not the most correct way to go. Instead I think he was proposing the more classical approach of actually thinking about the problem description and mentally tracing through the program, or for larger programs, using a piece of paper. But I can't talk for him. Let's see if he'll have time to answer. :) > > No brilliant piece of code was ever produced this way. Worse still, > > some student just copy their classmates work and then do cosmetic > > search-and-replace. > > that is what we called reverse-engineering.... still part of the > educational system.... many professional programmers are doing this... Reverse-engineering? I always thought reverse-engineering meant figuring out how the pre-binary code of a particular binary executable would look like based on an existing program whose source is unavailable, and "hacking" things from there to use (steal?) what can be used from it. Or for hardware's case when specs are not available to again by trial-and-error go through things in the development phase of a particular driver. OTOH I'd say a cosmetic search-and-replace where source is available (or stealable) would be plain and simple cheating. Hmm... > > Let us write a program that is correct in the first place, so that > > there is no need to debug it. > > nahhhh i dont believe in this.... creating a mistake makes a person or a > programmer more intelligent... so therefore dont expect a newbie > programmer to perfect this kind of philosophy... I think DocMana was pointing out how most modern-day programmers spend very little time thinking about the problem at hand before actually hacking away at the keyboard and then "debugging" it most tediously afterwards by trying various test cases (and like he validly pointed out: more often than not missing obscure cases that will eventually rear their ugly heads of terror). I don't think he implied perfectness. Of course one will err, that's human. But the need to test case-by-case brute force can be significantly reduced by giving both problem and program design enough thought before actually going through the nitty-gritties of hacking away with your PL of choice. --> Jijo -- Federico Sevilla III :: [EMAIL PROTECTED] Network Administrator :: The Leather Collection, Inc. GnuPG Key: http://jijo.leathercollection.ph/jijo.gpg _ Philippine Linux Users Group. Web site and archives at http://plug.linux.org.ph To leave: send "unsubscribe" in the body to [EMAIL PROTECTED] To subscribe to the Linux Newbies' List: send "subscribe" in the body to [EMAIL PROTECTED]
