🚀 go-pugleaf

In article <9000007@uiucdcsp> johnson@uiucdcsp.CS.UIUC.EDU writes:
>> 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.

So?  Admittedly these are well-known people, but do you really have any
idea what the goals of that particular project were?. It wasn't
necessarily to remedy any crucial programming envrionment deficiency.
More likely, it was to experiment and see what the realm of possibility
of a retro-fitted type system were.  After all, PARC is a research
lab.  Let's quit the name-dropping.

Having done a LOT of Smalltalk-80 programming in the last two year, and
having spent most of last year working on my own type system and
optimizing compiler, I am very inclined to agree with the >>
quotation.  As a programmer, I feel no NEED for a type system in
Smalltalk.  The rich set of tools provided by the programming
environment eliminate the need for much of the hand-holding provided by
a strong type system.  I VERY rarely get doesNotUnderstand: messages,
and it is not clear to me that one can come up with a type system to
get rid of the remaining few, or if it is worth the effort to do so.

The only real uses for a type system that I can see are to 

a) Expand the realm of compiler optimizations possible in order to
increase system speed.  The key thing that a type system adds is the
ability to statically bind some of the method lookups.  Once this is
done, then methods tend to look a lot more like classical language
procedures, and become much more amenable to classical optimization
techniques (code motion out of loops, tail recursion elimination, loop
unrolling, array index factoring, etc...) Note that this is NOT in
conflict at all with the current language or the current flexible
progamming style.  One can treat type declarations soley as HINTS and
allow the programmer to violate them at will but perhaps suffer the
cost of decreased speed.

b) Improve documentation for novice users.  A crude, ad-hoc, and 
etherially (sp?) defined type system is already found in many of the
class commments.  The default comment (at least in my ST image :-)) 
provides templates for each of the instance variables and a place to
describe the ``type'' of the variable.  A real type system could
formalize this and be able to actually make use of the information.
We have the added bonus that programmers unfamiliar with the class
can get an idea of what the class feels like by looking at its type
declarations.  This, coupled with the easy ability to browse any 
reference to an instance or class variable gives a very quick way to
get an idea of the purpose of any particular variable.


	-bob atkinson
	BAtkinson@Xerox.com
	BAtkinson%Xerox.com@CSnet-relay.csnet
	or any other incantation that gets you to the arpa net