Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!psuvax1!rutgers!mit-eddie!xn.ll.mit.edu!xn!olson From: olson@juliet.ll.mit.edu ( Steve Olson) Newsgroups: comp.lang.misc Subject: Re: Run-time Type Errors in Smalltalk Message-ID: Date: 16 May 91 17:54:13 GMT References: <1991May13.082152.29294@tkou02.enet.dec.com> <1991May15.141839.20603@daffy.cs.wisc.edu> <1991May16.011804.21042@tkou02.enet.dec.com> <1991May16.134106.24421@daffy.cs.wisc.edu> Sender: usenet@xn.ll.mit.edu Organization: M.I.T. Lincoln Lab - Group 43 Lines: 29 In-Reply-To: quale@saavik.cs.wisc.edu's message of 16 May 91 13:41:06 GMT In article <1991May16.134106.24421@daffy.cs.wisc.edu> quale@saavik.cs.wisc.edu (Douglas E. Quale) writes: The point is, I don't care what numeric type i is. In a dynamically typed language this type error would not occur. In dynamically typed languages a lot of things that can be type errors in static languages simply *cannot* cause errors. I think much of the belief in the extra safety of statically typed languages is based on experience with C, where uncaught type errors are a common and serious problem. C is a terrible example that gives all of the disadvantages of static typing with very little safety in return. -- Doug Quale quale@saavik.cs.wisc.edu I agree with that, but as was pointed out to me previously, when we think we are debating static vs. dynamic typing, we sometimes are actually debating abstract types vs. machine types. I think that a lot of type errors come when types that are conceptually very similar to a human are not at all the same to the machine. I make an order of magnitude more type errors in Common Lisp when I insert type declarations for optimizing purposes. All of a sudden the difference between int and float and whatever becomes very important, and it *is* hard to keep it all straight without help from the compiler. -- -- Steve Olson -- MIT Lincoln Laboratory -- olson@juliet.ll.mit.edu --