Newsgroups: comp.object,comp.lang.eiffel,comp.lang.c++,comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!rochester!udel!delmarva.com!newsfeed.internetmci.com!news.sprintlink.net!in2.uu.net!world!bobduff
From: bobduff@world.std.com (Robert A Duff)
Subject: Re: Why is one OO language more productive than another?
Message-ID: <DEL4Du.MCv@world.std.com>
Organization: The World Public Access UNIX, Brookline, MA
References: <40t027$7j9@hardcopy.ny.jpmorgan.com> <40vashINNgo8@bhars12c.bnr.co.uk> <9523600.18871@mulga.cs.mu.OZ.AU> <26jg07$031@zoe.pcix.com>
Date: Fri, 8 Sep 1995 11:39:30 GMT
Lines: 74
Xref: glinda.oz.cs.cmu.edu comp.object:38060 comp.lang.eiffel:10762 comp.lang.c++:147988 comp.lang.smalltalk:28107

In article <26jg07$031@zoe.pcix.com>,  <traymond@pcix.com> wrote:
>In <9523600.18871@mulga.cs.mu.OZ.AU>, fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:
>Sounds good, but there is a lot more to it than that.  Suppose you had
>been using smalltalk instead of C++, now what would happen if a message
>or operation had been performed on one of those 'mistyped' variables?
>It is possible, and very likely, that with many of them nothing would
>have happened because the way the variable was used was correct, so
>that the message being sent was defined in the receiving object and
>would have worked.  It is just that the declaration was wrong.  In
>other cases you get a 'doesNotUnderstand:' message the first time
>the message is sent, and that is just as easy and fast to fix as
>correcting a declaration.

The problem is that you get the doesNotUnderstand: message only when the
"type mismatch" happens on the *target* of the message.  If there is a
type mismatch on an argument, or on an assignment, then the error is not
detected at that time, because Smalltalk doesn't provide any way to
declare what the expected type is, in those situations.  So, you can
have a bug that causes an object of the "wrong" class to be passed as an
argument.  This wrong piece of data is then copied all over the place,
passed to zillions of methods as a parameter, saved away in some other
data structure, and then, much later, you get a run-time error when
somebody happens to send a message *to* that wrong object.  But that's
long after the actual cause of the bug.  In my experience, this makes
debugging Smalltalk code much more difficult (for this particular kind
of bug, anyway).  In a strongly typed language (even a run-time-typed
one), the bug would be detected as soon as you assign the wrong object,
or try to pass it as a parameter.

>Typing is of most value to the compiler.  If the compiler does not
>need typing then its value is greatly reduced.

I disagree.  Here's one piece of evidence: Smalltalk programmers
typically (in the code I've seen) encode the data type in the name of
the parameter, and/or in a comment.  E.g. an argument name might be
aString, indicating that this message wants an argument of class String
(or a subclass).  The fact that people put this information in their
programs seems to indicate that it is useful information for the human
reader of the program, and not just for the compiler.

This information would be much more useful if Smalltalk ensured (perhaps
at run time) that the information was really true (which it can't do,
since it's merely encoded in a name, or a comment).

>The only case where typing catches significant errors during program
>development is where the program logic is wrong and the wrong message
>is being sent to an object.  I would contend that the number of
>situations where this occurs is a lot smaller.  I would say that the
>cost of using typing to catch these errors it simply too high.

I'm not sure exactly what you mean by the above paragraph.  As I said
above, it is useful to detect type mismatches on *all* the arguments,
not just the special "self" or "this" argument used by some OOP
languages.  It is also useful to detect these errors when assigning.
E.g., an object might contain a "count", which is supposed to be an
integer number.  Some code might assign a String to it, and then go off
and do all kinds of other stuff.  The bug is detected only when somebody
tries to increment the count.

You say "a lot smaller".  Than what?  Bugs are cases where the program
logic is wrong.  So if typing only catches cases where the program logic
is wrong, then what is the problem?

>The reason I would like some sort of typing in smalltalk is that
>it helps the programmer understand what an existing program is doing.

Now I'm really confused.  This seems to contradict your opinion above,
which says that type information is mainly useful to the compiler.
I certainly agree that if the programming language allows the programmer
to encode type information, and this information is checked (at compile
time if possible, at run time otherwise), then this helps the reader
understand the program.

- Bob
