Mark Guzdial guzdial@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
squeak-dev@lists.squeakfoundation.org