On Tue, 15 Jan 2002, Sacha Chua wrote:
> However, we don't really teach good programming and debugging practices > in school. <ruefully> Even the teachers tend to use printfs to 'debug' > their code. I'd like to change that.. should be fun, you think? Ideally, your program should already be error free and thoroughly debugged, even before you sit down to type the code. We did "paper debugging" in the late 1960s, and the thing worked for us, and I do not see why it should not work for you today. This is how we used to debug: The machine we used was the IBM1620 at UPLB. There is no hard disk and no bootstrap rom. You typed the bootstrap program on the IBM-typewriter-console, and the bootstrap program loaded the "OS+FortranIIcompiler" from a deck of punch cards. The computer is really "alive" only after the FortranIIcompiler is loaded. You had to punch your source code on cards, one line per card. You threw the card away if you mispunch a character. You were lucky if the card punch machine also typed the character on top of the card so you can read the character. With a non-interpreting card punch, you read the holes that are punched. We quickly became experts at hole reading. The Fortran compiler will ask you to load your source deck and then push the "read" button on the IBM 1443 card read/punch. Your source deck was read in and if there are no syntax errors, an "object deck" was punched. Optionally, you can get a printout of your source code. The Fortran compiler now asked you to load the object deck (but you need to transfer the "symbol table" cards from the back of the deck to the front of the deck), which the machine reads in and executes. If there are no runtime errors, then you have a big celebration. Otherwise you have to go through the entire tedious and long process. There was no debugger, whether commandline or gui. If there was an error (syntax or runtime) you had to read your code and find out what's wrong with it. So we learned to do paper debugging. We wrote (handwritten) a clean version of our program on paper and manually simulated / walked- through our code, testing it with sample data and computing by hand. By the time we were done with this paper debugging, our program on paper was guaranteed error-free. We could actually boast that our programs ran on first typing and first compile. I believe that paper debugging is a good programming practice. It takes you away from the monitor and its dangerous radiation. It gives you time to think out your program, which you should have done in the first place! Happy programming to you, and may your tribe increase! PMana _ 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]
