At 8:59 -0500 1/28/2000, Mark Guzdial wrote:
>> > Does anyone know of any empirical evidence for the value
>>> of types?
>>> Or is it a myth that we invented to rationalize the typing
>>> needed to improve the compiler's performance?
>>
>>Peter Norvig's book "Paradigms of Artificial Intelligence Programming: Case
>>Studies in Common Lisp", 1992, Morgan Kaufman Publishers Inc. comes out
>>strongly in favour of type-declarations, citing a case on page 318 where
>>various hints to the compiler give a 40x speedup, so I see no need to
>>rationalize.
>
>I do believe that types lead to better compiler output -- I agree, no need to rationalize that.  The "value" that I'm questioning is that types lead to more bug-free code, that types "catch errors at compile time."  That claim seems untested yet, and I'm not even sure where it came from.  Is it a rationalization, e.g., "Well, we have to have types to make the code better -- let's claim that it's good for the programmer to use types! Improves their thinking, let's say!"  Well, maybe...
>
>Mark


Mark (and others):

I agree that types lead to better compiler output, but SELF showed that that doesn't mean the programmer has to *write* those types (nor actually write those classes either).

I believe that types came from having to know what went into a memory slot, just like in assembler. Early languages, like FORTRAN for which the first real compiler was built, concentrated on making it simpler to write logic. Obviously, a memory location had to have a 'type' since the compiler had to know what instructions to generate to implement the logic.

Most everyone since has grown up with languages that have types, and consider them how god intended programs to be. (This list is populated by a fair number of exceptions!) Certainly languages that interface more directly with hardware (like C) need types, but languages where we want to get some real work done (like in Squeak) don't need types.

 (Jean Sammet's 1969 book Programming Languages surveys virtually all high level languages prior to 1969; it's quite interesting to read about those early languages and how hard it was for the authors to get even simple things right.)


However, programs don't just sit there statically. Programs run. Type checking is static.

Smalltalk doesn't even have types if one uses the standard dictionary definition of type; Smalltalk has classes which are quite a different thing. But Smalltalk does not require that an instance of a specific class be passed or assigned, nor does it require an instance of one of its subclasses be used as the only alternatives.

Smalltalk allows, and programmers pass, any kind of instance which has enough of the right protocol that it won't fail. If a passed object is sent #nextPut:, #nextPutAll:, and #cr, then anything that responds to these three messages is OK to pass.

This isn't some kind of evil to be eradicated, but a true language feature unavailable in most other languages. Look around in Squeak; how often is, say, a stream passed and how often are these streams related only by their protocol?

So is this set of messages the 'type' of the parameter? It seems to me that it's these messages sent to an object in a context that matter. What do we gain by specifying them?


Dave

"Types are static; programs are dynamic."
_______________________________
David N. Smith
IBM T J Watson Research Center
Hawthorne, NY
_______________________________
Any opinions or recommendations
herein are those of the author  
and not of his employer.