[net.followup] Type checking and bugs

bob (06/01/82)

It has been my experience that I make far fewer mistakes when I write
LISP code than when I write Pascal code, yet the latter has lots of compile-
time type-checking strength.  I think that part of the reason is that clean LISP
is an applicative language whereas Pascal is imperative, the difference being
(if you're not familiar with prog lang lingo) that Pascal has a store (i.e.
variables) whereas clean LISP does not ("clean" LISP does not have any of the
imperative features like (GO ...) or (SET ...)).  I think that type checking
is most important for helping you keep track of the store, which is a nasty
undisciplined construct in the absence of some sort of type structure.
This is not to say, of course, that some type discipline is not useful in an
applicative environment (see, for example, the applicative subset of Russell).

anton (06/06/82)

The LISP/PASCAL comparason reminds me of a word of wisdom, uttered one sombre
day by the local guru when I was learning my trade.

It took me years to understand.  I *think*  it means work in terms of states
(e.g. the Aho/Ullman way of reading ALGOL 68 numners (Principles of compiler design et al) 
instead of the Russell&Randal (Algol 60 implementation - remember that ?))
rather than store lots of flags and variables.

However, I would put a qualifier on the matter.  In assembly code, the lack of
type checking is a trap for the unwary;  in PL?1 the repertoire of type
conversion done by the compiler can lead to a great seperation of what you
write from what the machine does.

Another word of wisdom from my old guru is that the more restrictive HOL's
lead to a faster delivery, since, among other things, you have to think about
what you are going to do before attempting it and getting it wrong.  On this
basis, abd despite the perfectly correct comments about ti that have come
out of the writing of "PASCAL Software Tools", in a world full of newly
graduated programmers, and whiz kids who grew up on PETS, trying to write
code for a production level project (ICBM's Three-Mile-Islands, ...... hell,
even just flight control systems for Boeing's NEXT generation of passenger
jets) the need to make them think first is not a bad thing.

My own personal experience with C, even after 5 years, is that a compiler
with stricter type checking and semantic knowledge (more so than LINT)
would be useful as a development option.

(Hmm typo on PL?1 may have been a good idea)

	Anton Aylward
	..!decvax!hcr!anton