Mark Guzdial <guzdial at cc.gatech.edu> wrote:
> >In the one and only case in my experience in which I advocated using
> >Smalltalk for a significant project, the "technical" folks on the
> >project voted the idea down in favor of Java, which they believed to
> >have advantages in performance, type safety, and market acceptance.
> >Draw what conclusions you like from this, but don't a priori assume
> >that "management" is the source of all difficulties.
> 
> So, I've taken to asking students (in oral exams, office hours, and 
> the like) what evidence they have that "safe types" buys them 
> anything?
> 
> "The types help the compiler catch errors in the program," they 
> respond.  I ask them if the types really do.  Do the warnings really 
> point to errors, or just type problems?  Are they errors that you 
> would have found easily and quickly without the types?  Then there's 
> the cost of types.  Casting, declaring types, and fixing code to 
> address warnings takes a good bit of time.  Is the cost worth the 
> benefit?
> 
> But this is actually more than me being "pedagogues who look on their 
> profession as an opportunity for pederastic abuse" :-)  I'm seriously 
> interested: 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?
> 

Let's leave aside for now the "types" assigned to the interface of a
component, and talk about building monolithic software.

First, most people, when pressed, will either back off of the
type-for-safety argument or just become silly.  (no types?  what a silly
idea).  Sometimes they'll say they find errors more quickly, but this is
a thin argument if your unit tests run as quickly as their compiles do.

That leaves three arguments that actually are viable:

	1. Types help with speed.
	2. Types form a basis for formal proofs.
	3. Types help programmer understanding.


The first two are not very important to most people.  That leaves
understanding.  

So.  How much information does a type annotation provide?  How much does
it matter if the annotations are checked by the compiler or by the
runtime?  (Dynamic checks have the advantage that one type anontation
won't virally infect the rest of the system.)  And how does all of this
compare to the benefits of writing unit tests?

Once a person can blow off safety, speed, and proofs, which is usually
easy, understanding is the real question they should address.  And when
you think about it, a type system developped for understanding would
probably *not* be the same as one designed for any of the other purposes
(with the possible exception of proofs).

Understanding seems to be the crux of the debate nowadays.  Like Java,
types were introduced for a specific purpose, but the true reason keeps
morphing over time.

Lex