Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utcs!mnetor!seismo!ll-xn!cit-vax!susser From: susser@cit-vax.UUCP Newsgroups: net.lang.st80 Subject: Re: Typed Smalltalk Message-ID: <803@cit-vax.Caltech.Edu> Date: Tue, 15-Jul-86 03:01:34 EDT Article-I.D.: cit-vax.803 Posted: Tue Jul 15 03:01:34 1986 Date-Received: Tue, 15-Jul-86 06:58:25 EDT References: <546@watmum.UUCP> Organization: California Institute of Technology Lines: 64 Gordon Cormack 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.