Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!rochester!ritcv!ccivax!rb
From: rb@ccivax.UUCP (rex ballard)
Newsgroups: net.cse
Subject: Re: working programs
Message-ID: <502@ccivax.UUCP>
Date: Thu, 20-Mar-86 17:06:25 EST
Article-I.D.: ccivax.502
Posted: Thu Mar 20 17:06:25 1986
Date-Received: Sat, 22-Mar-86 22:22:24 EST
References: <9431@ritcv.UUCP> <244@umcp-cs.UUCP> <2213@jhunix.UUCP> <455@ucsfcca.UUCP>
Reply-To: rb@ccivax.UUCP (What's in a name ?)
Organization: CCI Telephony Systems Group,  Rochester NY
Lines: 105
Summary: Functionality first, style a close second.

In article <455@ucsfcca.UUCP> dick@ucsfcca.UUCP (Dick Karpinski) writes:
>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.
>
>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.

This is a design problem.  The teacher should be able to write a good
complete specification of the problem, or the students should be able
to complete it.  The easiest specs are "here are inputs, this is what
the outputs should be".

>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.

Agreed, the ability to enhance a system is important.  The solution
is simple, assign the first spec, then assign the enhancements.
That's how it's done in the real world :-).

>Thirdly, the test-it-till-it's-perfect school fails badly.  Almost
>any real program is entirely too complex to test comprehensively.

True, but most complex systems are built from "trivial units" or
should be.  These are quite easy to test.

>Just consider the combinatorial effects of taking say three 
>full word parameters.  The universe has ended before the testing
>is complete.

The typical industrial approach is to test with "known good" data,
then "known bad" data, then "pseudorandom" data.  Yes, there might
still be a particular case where the algorythm won't work, but
the chances of finding it in a standard functionality test are slim.
Usually, these problems are things like "windows of error" where
during a 5 us window something could theoretically go wrong (an
interrupt corrupts the stack...).  Even PDP-11 C compilers have
this problem.

>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 one course, taught by the company training department, the
teacher had us trade programs, THEN add an enhancement to the
working code.  We were evaluated based on how long it took
the other person to change the original.  It's a good assignment.

>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.

This requires that the model be acurate (functionally correct and working).
If the original model is defective, the changes will be harder to make,
reguardless of how "pretty" it is.

>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.

While I won't deny that making "the next guy's job easier" is important,
if "the next guy's job" is to fix old functionality before adding
new, then the original is more expensive (we pay programmers) than
it should be.

>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 would love to tell you about all the "Beautifully Documented" programs
that required six weeks to write and twelve weeks for the enhancer
to understand, and required "fixing" almost weekly.  This isn't 
as bad as badly documented code, but almost.

Design (Yourdon, Jackson,...) should be a pre-requisite to building
"complex" systems.  If the student MUST learn a language first, then
trivial tasks should be used to teach it.  There are lots of good
excercises in some of the old BASIC books which could be used for
any language.

>
>I hope that there is at least something controversial above.

There was.

>
>Dick