🚀 go-pugleaf

Josh Susser <susser@cit-vax.Caltech.Edu> writes:
> I know this is anecdotal evidence, but it seems to me like Smalltalk has
> nothing on C for producing bugs that are anything but obvious.

C has a poor excuse for a strong type system.  Actually, it doesn't
even pretend to be a strong type system.

> I think static type checking would necessarily destroy the polymorphic
> nature of Smalltalk.  Types would have to be declared and message
> bindings checked at compile time.  Even allowing that variables could
> be one of several specified types, how would you deal with performs,
> or with applications that created new classes on the fly?  

One way to implement perform is to make a string representing the message
and evaluate it.  Evaluation calls the compiler, which type-checks the
expression, so type-safety is maintained.  This would probably be quite
slow, which would be ok by me, since I think that performs are ugly and
unnecessary.  (I think that I'm probably in the minority on this point.)
Creating new classes by applications is no harder than creating new classes
by the browser.  Of course, this does not necessarily mean that either is
easy.

> What if you
> overrode an inherited message in a subclass - what would happen to the
> already set binding to the superclass's method?  

Are you overriding the TYPE of the method or just its code?  Overriding
the code is no problem at all as long as the types are compatible.
Some type systems require that types of redefined methods be compatible
with the method being redefined, some do not.  Adding a type system
does not necessarily change the implementation of the language at all.
Even if the compiler performs some optimizations, it will still have
to implement some Smalltalk programs pretty much the same as it does
now, using method look-up.

> What if I wanted to
> make a subclass of ByteArray that masqueraded as a Float but had
> infinite precision (similar to LargeIntegers) - would this be a type
> clash, or would I have to cast the LargeFloat as a regular Float?

The subclass of ByteArray is not a Float.  However, it acts like a Float.
You should not usually write code that requires objects to be in a
particular class.  Instead, you should require that objects have certain
behavior.

> Even in a well-implemented system, static typing would be much more
> work for the programmer.  And, I maintain, all this extra work would be
> of no benefit, and probably some detriment.

A real type system for Smalltalk (as opposed to a toy type system for only
a part of the language) has to address all these questions.  Ideally,
static type checking should be virtually invisible to the programmer.
This is why many of the early papers tried to invent type inference systems.
I don't think that useful types can be inferred from Smalltalk programs
(I would be glad to be proved wrong) but it should still be possible to
remove almost all the burden from the programmer.  At the moment, I think
that it should only be necessary to have the programmer explicitly type
instance variables and to infer the types of methods and other variables.

> Smalltalk does not need strong typing.  Try writing a large system in
> Smalltalk.  Go ahead, I dare you.  You will find that you have
> absolutely no need whatsoever for strong type checking.  If my
> arguments will not convince you, then experience is the only thing
> that can.  If experience will not convince you, then you deserve to
> program in a strongly typed language. :-)

Note the authors of the following paper.

A.H. Borning and D.H.H. Ingalls.
A type declaration and inference system for Smalltalk.
In Conference Record of the Ninth Annual ACM Symposium on
   Principles of Programming Languages, pages 133--139, 1982.