Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!husc6!ut-sally!utah-cs!shebs
From: shebs@utah-cs.UUCP
Newsgroups: comp.edu
Subject: Re: software engineering
Message-ID: <4455@utah-cs.UUCP>
Date: Mon, 6-Apr-87 10:07:00 EST
Article-I.D.: utah-cs.4455
Posted: Mon Apr  6 10:07:00 1987
Date-Received: Thu, 9-Apr-87 00:09:41 EST
References: <7916@clyde.ATT.COM> <734@killer.UUCP>
Reply-To: shebs@cs.utah.edu.UUCP (Stanley Shebs)
Organization: PASS Research Group
Lines: 23

In article <734@killer.UUCP> elg@killer.UUCP (Eric Green) writes:

>...I must admit that I
>learned most of my "C" by reading sources posted to the net (e.g. "Larn"), and
>frantically flipping thru my "C" book trying to figure out what was going on
>(ok, so I cheated at Larn, kill me :-). But that kind of activity has no
>relation to the usual "here's ten lines of bletcherous code, tell me what's
>wrong with it" type of thing.

Certainly students should be given only the best programs to read at first,
then maybe a bad one later, when they've learned what to retch and puke on...
In fact, adding a new critter or command to Larn could be very educational
(but I don't know if Larn is a "best program"!)

Finding out what's wrong with an ten line *algorithm* is a very important
task.  All the formal methods in the world can't prevent the mistaken
counting that leads to fencepost errors, and those sorts of bugs are
inevitably encountered by someone other than the original author....

>Eric Green   elg%usl.CSNET     Hacker-in-training, University of SW Louisiana

							stan shebs
							shebs@cs.utah.edu