[net.lang] CLU and Calvinism

chip@dartvax.UUCP (Brig ) (12/04/83)

A recent correspondent claimed that strong-typing was necessary
to prevent buggy programs.  That is, I think, its official aim.

There is a lovely, high-level language in the world called SETL.
It comes from NYU and was Ada's first implementation language.
One of its inventors was asked about CLU, Alphard, and the like.
"They make it hard to write incorrect programs," he said, "but
SETL makes it easy to write correct programs."

So, when defending strong typing to the death, stop and think:
is this the BEST way of writing clear, bugless programs?  Or has
the joy of Calvinism overcome all reason?

rpw3@fortune.UUCP (12/14/83)

#R:dartvax:-47200:fortune:15100003:000:3724
fortune!rpw3    Dec 14 03:21:00 1983

As one who used to use BLISS a lot, I agree. I much prefer a language
that is easier to use right, than one that is hard to use wrong. The
latter kind are generally terribly hard to use right, either.
(I'm curious to see "Turing".)

I liked BLISS. Compared to the choices on the PDP-10 in those days
(1971), it was a winner.

At a conference on machine-oriented higher-level languages (published
by North Holland), Wulf said that even though BLISS was typeless, the
errors they saw were NOT very often type errors. More often, it was
logical errors in algorithms, etc.

***FLAME ON***

As far as strong-typed compilers go, NO compiler less than human will
catch logic errors, and in fact, my experience is that type-checking
"support" encourages people not to read their own code after it passes
'lint' (or eq.), much less read anybody else's code.  The place for
type-checking, in fact the place for compiling at all, is AFTER the
program has been printed on paper (yes!), desk checked, walked through
by others, and found "perfect". THEN submit it to the auto-test to
catch that one last careless typo. The other way around (normal UNIX
practice) is to hack it until it compiles, then hack it until it passes
'lint', then (maybe) get somebody to look at the (25-line) screen over
your shoulder if there are still glaring non-functionalities. Such a
procedure guarantees that the program will be as buggy as a late
afternoon picnic.

As long as it is easy to get the compiler to do what you want it to
do, and the resulting (source) code is easy for others to read, the
fine details of the language and its typechecking are irrelevant.
A careful craftsman can use any good tool well; a poor one can break
the finest tool.

In fact, the tools that are "comfortable" to the average craftsman
may, just may, be tools that actively impede quality results.
Dijkstra's "...Truths That Might Hurt" are no less true for being painful.

It is time we quit looking under the light of fancy languages/tools
and faced the dark of ignor-ance of our real problem: the lack of
rigorous disciplines to accomplish our tasks. We used to criticize the
hardware guys, because their stuff was simpler. These days, the hardware
people build more complicated programs (VLSI chips) with fewer bugs.
Just goes to show that a very slow complier (6-10 weeks per "compile")
can actually improve quality! Large (>200 chip) PC boards are routinely
turned out on first "compile" (PC layout) with no errors by those
skilled in the art. Can we find no method of achieving the same?

A few methods have worked fairly well for me, such as those noted above
(desk-checking, etc.) plus such things as designing all data structures
before any code, etc.  Others are mentioned in such highly recommended
(by me) books as DeMarco's "Controlling Software Projects: Management,
Measurement, and Estimation" (Yourdon Press 1982), and Gries's "Science of
Programming" (Springer-Verlag 1981), to name a couple. They are no secret.

All such methods are somewhat painful to get used to, as they work by
cutting our speediness so as to give our intelligence a chance to
work. It is much more fun to "quick! kill the next bug!" than it is
to not have any in the first place. The truth is, by the time a program
is released to its users, fewer than half of the defects will have been
found (ref: DeMarco, p.226ff). Another quote from the same source:
"When you see a roach climbing up the wall of a restaurant, you don't
say, 'There goes THE roach', you say, 'The place is infested'."

***FLAME OFF***

Rob Warnock

UUCP:	{sri-unix,amd70,hpda,harpo,ihnp4,allegra}!fortune!rpw3
DDD:	(415)595-8444
USPS:	Fortune Systems Corp, 101 Twin Dolphins Drive, Redwood City, CA 94065