Comments on book review

[peters at cubsvax.UUCP]

Below are excerpts from fortune!crane's review of a new book on C programming.
I haven't seen the book, but the author's basic idea of how to program, which
crane shares, is the common textbook version that comes with the idea
of structured programming.  I've reproduced crane's comments below.

Now, my question is, does anyone really program this way?  I really want to
know!  I certainly *mostly* do what the author (see below) calls BUGGING.  When
I try to think everything out ahead of time, I find that before I get very far
I start being uncertain what the compiler, programming tools, etc., are
really going to do with the overall method I have in mind, and so I go in
and try it on elementary examples.  Then I end up extending these elementary
examples over and over, and combining them with other extended elementary 
examples, to make a program or package.  Then I clean it up at the end.  The
point is, it's an *iterative* process, not one in which I first plan, then
implement.

I'm sure that part of the reason I work this way is that I'm still not
completely comfortable with C and UNIX, but I tended to work this way even
in languages in which I felt very much at home.

{philabs,cmcl2!rocky2}!cubsvax!peters            Dr. Peter S. Shenkin 
Dept of Biol. Sci.;  Columbia Univ.;  New York, N. Y.  10027;  212-280-5517

>> From philabs!cmcl2!floyd!harpo!ihnp4!fortune!crane Wed Dec 31 19:00:00 1969
>> 
>> This is a review of the book "C Programmer's Library" by Jack J.  Pudrum
>> (author of "C Programming Guide"), Timothy C.  Leslie (Dir.  SWD @
>> Ecosoft), and Alan L.  Stegemoller (coauthor of Ecosoft's Eco-C C
>> compiler), published by Que Corporation, Indianapolis, 1984.
>> 
>> 0. Laying the Groundwork
>> 
>>         This chapter introduces the philosophy of the book and presents a
>>         methodology for developing generalized C functions.
>> 
>>*         This chapter comes down heavy on people who, having been given the
>>*         basic requirements for a program, immediately rush off to their
>>*         terminals and start entering source code.  The authors say: "These
>>*         students are not programming; they are BUGGING.  They will spend
>>*         ten minutes bugging and another DEBUGGING (that is, correcting) the
>>*         mess they will make in the first ten minutes." What you should do,
>>*         they say, is to spend 10-15 minutes anayyzing the problem (the
>>*         problem, by the way, is to write a program to sort 100 ZIP codes),
>>* 	then spend another 15 minutes coding and testing the program."
>>* 
>>* 	(I agree with the above.  I am not totally familiar with the term
>>         "hacking", but to me hacking is analogous with "bugging".  Somebody
>> 	correct me if I'm wrong.  In my opinion, both are to be avoided in
>> 	favor of a planned, deliberate approach to solving a problem.)
>>