os@primerd.prime.com (03/30/91)
I have been reading a book recently, "C Traps and Pitfalls" by Andrew Koenig.
I would recommend to anyone. The concluding chapter opens with the following,
which struck a chord with me and I'd like to share:
-------------------------------------------------------------------------------
You have just finished a tour through some of the ways that C program-
mers can hurt themselves. Like many of the people who read early drafts
of this book, you are probably wondering: "How can I avoid these prob-
lems?"
Perhaps the most important avoidance technique is to <<know what you're
doing.>> The most irritating problems stem from programs that appear to
work but have hidden problems. Because these problems are hidden, the
easiest way to detect them is by careful thought in advance. Fiddling
with a program until it appears to work is a reliable way of obtaining a
program that almost works.
The most eloquent statement of this I have seen appears, of all places,
in the construction manual for a harpsichord. It was written by David
Jacques Way, who clearly appreciates the importance of confident
knowledge, and with whose kind permission I reprint it:
'Thinking' is the cause of all error; I can prove this by
the fact that whoever makes a mistake always says, "Oh, but
I thought...." Never mind this kind of thinking - before you
glue anything together you must know. Put the parts together
without glue (called a 'dry run'), study how they fit, and
check with your drawing, which shows how everything fits.
And after you have put something together with glue, check
it again. I've heard the sad story so many times: "Last
night I did so and so, and this morning when I looked at it...."
Dear builder, if you had looked at it last night you could
still have taken it apart and put things right. Many of you
are building in your spare time, so the temptation is great
to work far into the night. But if I can believe my tele-
phone calls, most mistakes are made the last thing before
you go to bed. So go to bed before you do the last thing.
This advice is remarkably relevant to programming if one thinks of
"putting it together with glue" as combining several small pieces into
a bigger program. Understanding how the pieces are going to fit
before actually fitting them is one of the keys to a reliable result.
Such understanding is particularly important under time pressure.
Near the end of a long debugging session, it becomes tempting to try
things almost at random and stop as soon as something seems to work.
That way lies disaster.
-------------------------------------------------------------------------------
My own comments are along the opening line of <<know what you are doing.>>
Back in the old days people used to walk through their code offline. Now
we often twiddle until it compiles and the step thru with a debugger until
it works. We don't step back, offline, with a paper listing in hand to review
things by ourselves in a methodical manner. Some may reply that they are
covered by having an individual or a team perform a code review or code
inspection, but I claim that is too late. I want to be sure of things on
my own time, to know it cold, inside and out, both within a module and at
the overall system (of modules) level, before I waste someone else's time.
I want to know what I am doing.
Jim Cook
Prime Computer, Inc.
<J.Cook@ENS.Prime.COM> (Don't email to os@primerd).leipold@eplrx7.uucp (Walt Leipold) (04/02/91)
In article <49900005@primerd> os@primerd.prime.com writes: >Back in the old days people used to walk through their code offline. Now >we often twiddle until it compiles and the step thru with a debugger until >it works. We don't step back, offline, with a paper listing in hand to review >things by ourselves in a methodical manner. You know the (only) thing I miss from the ol' mainframe days? Fan-fold printer paper! I never got disoriented at a page boundary, the stuff was 132 columns wide so there was plenty of room for doodling alternate algorithms, the print was big (by modern standards), and if I got *really* confused, I found a long hallway, unrolled the entire source file, and crawled back and forth until I understood what was going on. Anybody know of a laser printer that handles fan-fold paper? My Imagewriter does, but it's not a *real* printer... >Jim Cook >Prime Computer, Inc. ><J.Cook@ENS.Prime.COM> (Don't email to os@primerd). -- -------------------------------------------------------------------------- "At twenty-six, Kate, though not Walt Leipold promiscuous, had slept with most (eplrx7!leipold) of the decent men in public life." (leipolw%esvax@dupont.com) -- The UUCP Mailer
amanda@visix.com (Amanda Walker) (04/02/91)
leipold@eplrx7.uucp (Walt Leipold) writes:
[...], and if I got *really*
confused, I found a long hallway, unrolled the entire source file, and
crawled back and forth until I understood what was going on.
Ah, memories. The use of a wall as a debugging tool is also very underrated
these days.
Anybody know of a laser printer that handles fan-fold paper? My Imagewriter
does, but it's not a *real* printer...
Well, you could plunk down a hundred grand or so for an ion deposition
printer (the kind of thing that bank statements and such are printed on).
I don't know of any cheap-but-fast-and-quiet continous-form printers,
though.
--
Amanda Walker amanda@visix.com
Visix Software Inc. ...!uunet!visix!amanda
--
I pray for boredom, but it never comes.zben@ni.umd.edu (Ben Cranston) (04/02/91)
In article <1991Apr1.190102.12345@eplrx7.uucp> leipold@eplrx7.uucp (Walt Leipold) writes: > You know the (only) thing I miss from the ol' mainframe days? Fan-fold > printer paper! I never got disoriented at a page boundary, the stuff was > 132 columns wide so there was plenty of room for doodling alternate > algorithms, the print was big (by modern standards), and if I got *really* > confused, I found a long hallway, unrolled the entire source file, and > crawled back and forth until I understood what was going on. When I want a listing of one of my assembly language programs: 1. My makefiles have "asm -L" statements, so a whatever.a.lst file gets made. 2. My makefiles have a "listing" target, like this: listing D catlist netprint.r dinstall.a.lst netprint.a.lst setup.a.lst 6 >harddisk:onsiteprint (You have to close your eyes and imagine that the "D" is a long script F and the 6 is a greek "del" character :-) So a "make listing" makes a file called "onsiteprint" containing the source of the resource file and the assembly language listing. The catlist proc looks like this: # catlist <files> If 0!={#} For name in {"Parameters"} echo 6f catenate {name} End Else For name in E If ("{name}" =~ /E.p/) || ("{name}" =~ /E.c/) || ("{name}" =~ /E.a.lst/) echo 6f catenate {name} End End End (Yeah, close your eyes and see the E as a double wavy equals sign...) 3. I run a mdqs qpr program on "onsiteprint" and send it to a unix machine via TCP/IP. If I ever get a spare minute I will write a MPW tool that does the catenation, the form feed between files, and the network send. This would compress steps 2 and 3 together. 4. The unix machine spools the printer files. The queue I spool to specifies routing to a Univac 1100 mainframe. 5. Software on the Univac 1100 receives the unix-format print file and converts it to Univac internal format, then to IBM print file format. 6. The IBM formatted file is sent via a HASP link to an IBM 3090 machine which feeds it to an IBM 3800 laser printer which prints nice listings on (ta da!) fanfold computer paper. Lots of width for dem assembly listings and lots of header and trailer pages to play tic-tac-toe on while waiting for all this stuff to happen...
russotto@eng.umd.edu (Matthew T. Russotto) (04/02/91)
In article <1991Apr1.190102.12345@eplrx7.uucp> leipold@eplrx7.uucp (Walt Leipold) writes: >You know the (only) thing I miss from the ol' mainframe days? Fan-fold >printer paper! I never got disoriented at a page boundary, the stuff was >132 columns wide so there was plenty of room for doodling alternate >algorithms, the print was big (by modern standards), and if I got *really* >confused, I found a long hallway, unrolled the entire source file, and >crawled back and forth until I understood what was going on. Wanna buy an Imagewriter 15"? $800 even. As is. -- Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu .sig under construction, like the rest of this campus.
Roger.W.Brown@dartmouth.edu (Roger W. Brown) (04/12/91)
In article <1991Apr1.190102.12345@eplrx7.uucp> leipold@eplrx7.uucp (Walt Leipold) writes: > You know the (only) thing I miss from the ol' mainframe days? Fan-fold > printer paper! Here at Dartmouth we still have it, or at least we have it again. We wrote a Mac print driver that connects to a network based printing monitor on a HoneyWell mainframe. All I have to do is choose the lineprinter in the Chooser, print my source from MPW (or anything else that prints text), wait a couple of minutes, and walk down the hall to the lineprinter room to get my source on old-time fanfold 14 inch paper. And all this in a building away from the computer center. Unfortunately, the lineprinter part is on a HoneyWell and is therefore not portable. We have thought about doing the same thing with a Unix host, but the Mac end uses PAP and Unix doesn't know that. I guess it wouldn't be that hard to switch it to TCP/IP. We wonder about the demand for such a thing out there in the rest of the world. Looks like there is some. Roger W. Brown Courseware Development Dartmouth College Hanover, NH