Re: OO, C++, and something much better!

["Norman H. Cohen" <ncohen@watson.ibm.com>]

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