Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!udel!haven.umd.edu!socrates.umd.edu!socrates!rockwell From: rockwell@socrates.umd.edu (Raul Rockwell) Newsgroups: comp.lang.misc Subject: Re: Run-time Type Errors in Smalltalk Message-ID: Date: 9 May 91 05:43:01 GMT References: <3865@ssc-bee.ssc-vax.UUCP> <530@eiffel.UUCP> <1991Apr28.022234.287@odi.com> <2604@calmasd.Prime.COM> <1991May9.023313.28308@tkou02.enet.dec.com> Sender: rockwell@socrates.umd.edu (Raul Rockwell) Organization: Traveller Lines: 57 In-Reply-To: diamond@jit533.swstokyo.dec.com's message of 9 May 91 02: 33:13 GMT me: Consider an arbitrary program, with (for example) several thousand me: variables and a few dozen types. If the program says: f(x), what me: does static typing buy you, security-wise? You can only me: misidentify x a few hundred ways instead of a few thousand? me: (Awesome reliability there). Norman Diamond: Exactly. In this scenario, if you misidentify x, there is a 90% chance that your error will be caught. This is 9 times as valuable as a case previously discussed, where other fields of engineering value a 10% improvement in safety. Enumerating the number of ways a variable may be misidentified does not properly identify the chances that it will be caught. Run-time insanity checks can provide a degree of robustness that is not available using only compile time checks. Just because your language will not catch certain errors except with static typing doesn't mean that my language has the same problem. Also note that dynamic typing allows wonderful properties in a debugger. Note that I'm classifying as type checking: array bounds checking, un-assigned variable checking, range checking, storage class checking and exceptional values checking. A compiler can catch some instances of un-assigned variables, and some instances of storage class checking. It's not going to be able to check anything dynamic (except the static references). A really good compiler might be able to catch _some_ instances of value out of range. Ultimately, making the programmer work to make sure that variable Quad is not assigned to variable Tape is not going to do anything to make sure that Quad is being used correctly -- it's just going to make sure that one of many stupid mistakes is not made. me: Unless you are intending to allow only one instance of a type in me: any lexical name-space? That would be security! [And you'd be me: writing your program at least twice, once in "type expressions", me: and once in "imperative expressions". There's nothing quite like me: trying to keep two versions of the same thing in sync to improve me: reliability...] Norman Diamond: Although excessive and rhetorical, this also has its value. Why did businesses used to use "verifiers" on their punched cards for data entry? Why do fault-tolerant machines compute many results twice? You'd better believe there is nothing like redundancy to improve reliability. Why do some machines associate type with a variable at runtime? Could it be because there is nothing like redundancy to improve reliability? (yeah, I'm leaving out an issue here: additional features which come with a typing system. Some such features are gratuitous, some are so significant that they make reliability arguments pale.) Raul Rockwell