johnson@m.cs.uiuc.edu (10/29/90)
There are at least three different uses of types: for static checking to eliminate errors for documentation for code optimization. My research has concentrated on the third use, but in the long run it is probably the least important. People have focused on the first use in previous postings, so I will concentrate on the second use. I teach a lot of people Smalltalk. This semester my class on object-oriented programming and design has over 50 graduate students in it and a few undergrads. These are bright students, and they have little trouble in picking up the basic concepts of object-oriented programming in general and Smalltalk in particular. However, it takes most of the semester to learn the class libraries. People are always tripping over the same problem, such as that add: returns the element being added, not the collection to which it is being added. Good documentation is essential. In fact, I think that the main reason that type-checking is important in a large system is for communication between people working on its different parts. Checking is important, but communication is more important. Smalltalk has a number of conventions for documentation. Variable names are chosen to encode their type, and class comments are supposed to describe the type of every instance variable. However, these comments and names are often wrong or misleading. Documentation should be an essential part of a program, and its truthfulness should be checked as much as possible. In my opinion, type systems should be much more flexible and powerful than they are now. For example, it is common for a sort routine to be parameterized by an ordering predicate. It is possible in many type systems (including my own) to say that the sort routine takes a Collection of T and a function TxT->Boolean, but it is not possible to say that the function is a total ordering on T. I want to include as much information as possible about a program. It will be good documentation, if nothing else. However, to be most useful, it should also be checked statically, and it would great if the compiler could use it to produce more efficient code. Of course, extending type systems like this is likely to lead to type systems that are not decideable, so it is much easier to say that I want an expressive type system than to design and implement one. Most type-checkers are not incremental. Thus, changing a program requires massive recompilation. Smalltalk and Lisp programmers know the joys of a dynamic programming environment, and are not willing to give it up. However, there is no reason that type-checking cannot be incremental or for a language with static type-checking to permit the same kind of programming environment provided by Smalltalk. This is more a matter of programming environment design than language design. In the long run, I don't think we will have to make a compromise between static type-checking, dynamic binding, instantaneous compilation, and efficient execution. Or rather, the compromises will be much less severe than they are today. However, there is still a "little bit" of research that needs to be done to make everything work out. Ralph Johnson - University of Illinois at Urbana-Champaign