Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site ucsfcca.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!ucsfcgl!ucsfcca!dick
From: dick@ucsfcca.UUCP (Dick Karpinski)
Newsgroups: net.cse
Subject: Re: working programs
Message-ID: <455@ucsfcca.UUCP>
Date: Mon, 17-Mar-86 03:53:51 EST
Article-I.D.: ucsfcca.455
Posted: Mon Mar 17 03:53:51 1986
Date-Received: Wed, 19-Mar-86 00:55:52 EST
References: <9431@ritcv.UUCP> <244@umcp-cs.UUCP> <2213@jhunix.UUCP>
Reply-To: dick@ucsfcca.UUCP (Dick Karpinski)
Organization: UCSF Computer Center
Lines: 63

In article <2213@jhunix.UUCP> ins_asac@jhunix.ARPA (Stephan Alexa Cooper) writes:
>>Maybe writing better specifiactions would help.  But giving the majority
>>of the credit for style doesn't seem to be the answer.
>
>As for the majority of grading on style, you've got to be kidding!  I grant,
>style is VERY important, but if the program doesn't work, style's not going
>to make it work any better.  Pretty programs do not always work best.
>How are you going to give a good grade to a program that is supposed to
>(for example) manipulate lists of structures (C) if it only looks good,
>but doesn't work?  Style should be considered AFTER the making the program
>work.  I don't mean "write the program, get it to work, then re-structure
> ...
>What I mean is that in the grading process, style should be that thing which
>decides whether the program is an 'A' or 'B.'

I do not agree.  First of all, there are very few programs that work.
That is, a program which is said to work should have a specification.
Few specifications exist.  There is a whole lot of "you know what I
mean" in the attempts I see.  In light of these facts, the exact
correspondence between specification and implementation is hard to
assert.

Secondly, the task is not even that easy.  Several deep thinkers
about computer programming point out that the design of a program
should establish the basis for a whole family of related programs.
The essence of that claim is that the outside world keeps changing
and demanding alterations to the function to be served.  A program
which perfectly meets its initial specs but cannot be altered is
of little value.

Thirdly, the test-it-till-it's-perfect school fails badly.  Almost
any real program is entirely too complex to test comprehensively.
Just consider the combinatorial effects of taking say three 
full word parameters.  The universe has ended before the testing
is complete.

I won't claim that good style is enough, but I would sure rather
fix and then change a clearly written program which fails than
to try to change a correct program which I cannot understand.
In particular, Michael Jackson's approach appeals to me.  He
says to build the program around a model of the situation in
which the program lives, rather than to perform the requested
function.  Then the changes in requested function can be 
accomodated easily, since they are mere window dressing on a
well constructed skeleton which remains clear and clean.

Remember that we are not writing programs to get the computer
to do the right thing!  Instead, we write programs to make the
next guy's job easier; to facilitate the inevitable changes.
The first thought should be to make the program obvious to the
casual reader.  Bugs in such programs are not the major problem
that they so often are in more conventional (bad) programs.

I hope that there is at least something controversial above.

Dick

-- 

Dick Karpinski    Manager of Unix Services, UCSF Computer Center
UUCP: ...!ucbvax!ucsfcgl!cca.ucsf!dick   (415) 476-4529 (12-7)
BITNET: dick@ucsfcca   Compuserve: 70215,1277  Telemail: RKarpinski
USPS: U-76 UCSF, San Francisco, CA 94143