From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public From: "Norman H. Cohen" Subject: Re: OO, C++, and something much better! Date: 1997/01/23 Message-ID: <32E788D4.4B91@watson.ibm.com>#1/1 X-Deja-AN: 211710976 references: <32DF458F.4D5C@concentric.net> <32DF94DC.6FF8@watson.ibm.com> <32DFD972.37E4@concentric.net> <32E4FC5B.242C@watson.ibm.com> <32E6862D.608B@parcplace.com> content-type: text/plain; charset=us-ascii organization: IBM Thomas J. Watson Research Center mime-version: 1.0 reply-to: ncohen@watson.ibm.com newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng x-mailer: Mozilla 3.0 (Win95; I) Date: 1997-01-23T00:00:00+00:00 List-Id: Eric Clayberg wrote: > > Norman H. Cohen wrote: ... > > ... Once > > a program has been keyed in, strong typing results in a flurry of > > compile-time errors that must be addressed before the program will run. > > Of course dynamic typing does not make these errors go away, it just > > hides them so that you have to find them yourself instead of having them > > pinpointed for you by a compile-time error message. > > Not true. In a language like Smalltalk, those "errors" as you call them > are not hidden; they never existed to begin with. Having worked > extensively with several statically types languages (C, C++, Fortran, > etc.) and now having worked commercially with Smalltalk over the last > several years, I conclude that most "type" errors in statically types > languages are due to the complicated nature of their syntaxes and the > draconian rules of their type systems. Smalltalk doesn't have those > problems and doesn't lend itself to "type" errors of that nature. Almost > all "message not understood" errors are messages directed to nil (the > moral equivalent of a null pointer in C). You seem to be confusing type errors with all other kinds of compile-time errors. A type error is specifically an error in a syntactically WELL-FORMED construct that arises because the programmer has declared his intent to use a certain object in one way, but has been caught using it in a way inconsistent with this declared intent. For example, suppose a program has an array of "producer companies" that manufacture a particular product and an array of "consumer companies" that buy that product. Suppose the program manipulates both integers meant to index into the first array and integers meant to index into the second array. Mistakenly using a variable holding an integer of the first kind to index into the second array could produce subtle errors that might be hard to track down, or might just silently produce incorrect answers. In a strongly typed language such as Ada, one could write type Producer_Number is range 1 .. Max_Producer_Count; type Consumer_Number is range 1 .. Max_Consumer_Count; Producers : array (Producer_Number) of Company; Consumers : array (Consumer_Number) of Company; Producer_Number and Consumer_Number are distinct integer types whose uses cannot be intermixed without an explicit type conversion. (This is a degree of type protection unavailable in C or C++). Certain variables can be declared to be of type Producer and others of type Consumer. An attempt to use a variable of type Producer_Number to index into the array Consumers will produce a compile-time type error. As you said, "Smalltalk does not lend itself to 'type' errors of that nature." Smalltalk programmers are no less likely than other programmers to use an integer variable to index into the wrong array, but since Smalltalk does not have the means to express such distinctions as type distinctions, I would imagine that most Smalltalk programmers would think of this as a "general logic error" rather than as the kind of problem that would be caught by compile-time type checks. (When you don't have a hammer, none of your problems look like nails.) > It's funny that you should mention securities industry. Quite a few Wall > Street investment banks use Smalltalk for their securities trading > systems. I mentioned the securities industry specifically because Alan Lovejoy had brought up the use of Smalltalk in that industry. This industry has perceived that Smalltalk speeds deployment of software, but I suspect that few realize that this is accomplished by deferring the detection of some errors until after deployment! The appropriate comparison here is not to C++ (an error-prone language whose supposedly strong typing system is too weak to catch many of the errors that language fosters), but to a safety-oriented language such as Ada. Given the potential financial impact of an incorrect program, people in this industry ought to demand the same protection against programming errors that purchasers of safety-critical software demand. Then again, I suppose they wouldn't be in the securities industry if they didn't enjoy high-stakes gambles. :-) -- Norman H. Cohen mailto:ncohen@watson.ibm.com http://www.research.ibm.com/people/n/ncohen