🚀 go-pugleaf

In article <6565@alice.uUCp> ark@alice.UUCP writes:
>In article <672@unc.unc.UUCP>, rentsch@unc.UUCP writes:
>> Dynamic binding yields considerable advantages over Simula,
>> including more polymorphic procedures and incremental compilation.
>> (Those of you out there who have used Smalltalk and/or Lisp systems
>> know what I'm talking about.)  Basically, the only reason *not* to
>> have dynamic binding is the belief that "it costs too much".
>
>Not so.  Another reason to avoid dynamic binding is that doing so
>makes it easier to catch certain programming errors early on.
>The earlier an error is caught, the less damage it does.

Two different concepts are being confused here.
Smalltalk has Dynamic Binding because methods are bound to messages
at run time.  Smalltalk has Dynamic Type Checking because type errors
(ie, 'message not understood') are detected at run time.

I agree that dynamic type checking is a problem.  I had an opportunity
to play with Alan Bornings "ThingLab" and Randy Smiths "Alternate Reality Kit".
These are both large applications written in Smalltalk.
I was able to cause both programs to seize up with "message not understood"
errors just by playing around.  Although Smalltalk is great for rapid
prototyping, it isn't suitable for programming large, *robust* applications,
because you can never be sure that you haven't found all the type errors.

However, there is no reason why a language could not support static
type checking and dynamic binding.  For example, one could define
a statically typed variant of Smalltalk in which a 'type' specifies
the set of messages understood by an object.  We still have dynamic
binding (and polymorphism), because two objects that accept the same
message protocol are interchangeable at runtime, even if they have
different implementations.  But static type checking ensures that all
'message not understood' errors are detected at compile time.
-- 
Doug Moen (watmath!watcgl!kdmoen)
University of Waterloo Computer Graphics Lab