🚀 go-pugleaf

Gordon Cormack <gvcormack@watmum.uucp> writes:
> There is no doubt that dynamic typing and dynamic procedure binding
> like in Smalltalk offer the programmer a lot of flexibility.  However,
> they also make it very difficult to make assertions about what the
> program does.  I do not agree at all that "one quickly gets an
> obvious error message" when one runs an incorrect Smalltalk program;
> it may run for years before crashing, and when it does, the bug may
> be anything but obvious.

I will agree that incorrect Smalltalk programs do not always produce
obvious error messages.  The point I was trying to make was this: if
there were a type error in my program the 'does not understand'
message I would get at run-time would notify me of the error just as
well as a compile-time error report.

By the way, it's true that incorrect Smalltalk code can run for years
without crashing - just try using processes.  But I remember seeing a
book called 'The C Puzzle' or something like that that was a listing
of a very long, boring looking program that supposedly did something
very obvious.  Also included was the output of the program, which was
completely mistifying and entirely different from what you would
expect.  The puzzle was to find the error, a ONE CHARACTER mistake!  I
know this is anecdotal evidence, but it seems to me like Smalltalk has
nothing on C for producing bugs that are anything but obvious.

> So I am 100% behind any attempt to introduce static type checking
> (which would guarantee that the error "don't understand xxx" would
> never occur), provided that it does not destroy the polymorphic
> capabilities of the language.

I think static type checking would necessarily destroy the polymorphic
nature of Smalltalk.  Types would have to be declared and message
bindings checked at compile time.  Even allowing that variables could
be one of several specified types, how would you deal with performs,
or with applications that created new classes on the fly?  What if you
overrode an inherited message in a subclass - what would happen to the
already set binding to the superclass's method?  What if I wanted to
make a subclass of ByteArray that masqueraded as a Float but had
infinite precision (similar to LargeIntegers) - would this be a type
clash, or would I have to cast the LargeFloat as a regular Float?

Even in a well-implemented system, static typing would be much more
work for the programmer.  And, I maintain, all this extra work would be
of no benefit, and probably some detriment.

There is not a problem with the way typing is handled in Smalltalk
currently.  The vast majority of bugs in Smalltalk programs are not
type errors.  A type-checking compiler would not be a useful tool in
Smalltalk - there are already plenty of tools in Smalltalk to allow me
to make certain I know what I'm doing.  Static typing is for
early-bound, non-polymorphic languages.

Smalltalk does not need strong typing.  Try writing a large system in
Smalltalk.  Go ahead, I dare you.  You will find that you have
absolutely no need whatsoever for strong type checking.  If my
arguments will not convince you, then experience is the only thing
that can.  If experience will not convince you, then you deserve to
program in a strongly typed language. :-)

--Josh Susser
  susser.pasa@xerox.com (preferred email box)
  susser@csvax.caltech.edu

Smug was I ere I saw gums.