"Richard A. O'Keefe" wrote:
> 
> The thing that has to be understood is that there is a very heavy price
> to pay for NOT having a type system, and that to the extent that this
> analogy has any force in the argument at all, Smalltalk programmers are
> paying it.  What, after all, are "method signatures" as advocated by that
> IBM group and as used in the draft ISO standard for Smalltalk, but types?
> The whole argument for method signature comments is that there is an
> important dimension of Smalltalk design which is very hard for new members
> of a project to discern.

I would have to agree with you on this point- I've built a system
to find those signatures for the express purpose of creating information
so that Smalltalk programmers, both the original writer and their later
victims, would have an additional view of some chunk of code.  In my
case, the view I was after was to determine which objects were interacting
with each other, and determine what they expected out of those interactions.
This information is not given explicitly anywhere in Smalltalk, but it
does exist implicitly, and can be extracted.  I've been reluctant
to call it a "type" system, however- mainly because to me types have
a process-oriented connotation to them, though that is perhaps more
an issue of my own personal bias than what would be considered an
accepted definition.

An important point about my system would be that it does not do "checking"
of any kind- instead, it examines "in-use" evidence of what the programmers
wrote to build a picture of what they were claiming to be correct.  Whether
those claims were correct or not requires additional work, but the picture
it builds is often informative enough that I've usually been able to spot
discrepancies or unusual patterns of interaction fairly readily.


> Let me provide one personal experience which indicates why I think types
> are an important design tool whether they are supported by the underlying
> language or not.
> 
> I used to work at Quintus, back in the days when they were a Prolog company.
> When David Warren left (for a professorship in England) I took over maintenance
> of the compiler.  One day we discovered a bug in the compiler, and it was my
> job to fix it.  David Warren is one of the world's great hackers; he can come
> up with an elegant design and code it up before most people have finished
> their breakfast.  But at that time he wasn't one of the world's great
> Software Engineers.  To be blunt:  I couldn't figure out where the bug was.
> 
> I spent a week discovering, documenting, and writing test cases for the
> data structures used by the compiler.  The test cases were important; it
> was actually quite tricky to figure out some of the data structures from
> the code.  At the end of that time, I understood almost all passes of the
> compiler.  I was able to clean up some of the data structures to be more
> elegant (if you know Prolog, there were several "defaulty" structures; the
> revised code had a lot fewer cuts), and ended up with a compiler that was 20%
> faster and a *lot* more maintainable.
> 
> It turned out that the bug was in a part whose operation I never did
> understand, but now that I knew what the inputs and outputs had to look
> like, I was able to change the input so that the bug (though still in a
> sense _there_) never bit any more.
> 
> The interesting point here was that revising the data structures so that
> they were amenable to type checking and writing down what the types actually
> _were_ didn't just make the compiler 20% faster, they made it *far* more
> maintainable.  Now it was possible to ask questions like "does this
> procedure not handle that kind of thing because the coder forgot that case
> or because that case can't happen?" and not just ask, but find answers.
> 
> I also noticed that in well-commented Prolog code, the comments basically
> supplied the type information that *human beings* needed.  *People* were
> using types even when the compiler didn't.  Method signature comments are
> the same thing for Smalltalk.

I think that's the main point- a "type" system does not have to be a straight
jacket, but a means of providing additional information and comfort to the
programmer(s).  Smalltalk is sufficiently malleable that we can have
a "rabid" development stage followed by an informative illumination of
what has been written, or handle interface design up front and use Interface
objects to keep development under a watchful eye ( btw, Benny Sadeh has
SmallInterfaces available for this purpose ), or do neither and
just be happy when it works.


> In my rather cynical view, there'd be as high a proportion of software
> crud written in Smalltalk or Lisp as in C if it weren't for the fact
> that people who get interested in Smalltalk or Lisp are better programmers
> to start with.

By and large, I'm fairly impressed and occasionally outright amazed at
the things I've found in Smalltalk.  But there is still a fair amount
of crud.  A fair bit of mud, but enough diamonds to keep me enthused.
However, any time I think I might be a pretty decent Smalltalker I bear
in mind a comment that Ralph Johnson once made about Smalltalk making
even mediocre programmers look good.

Also, I've seen video of Alan Kay describe the class libraries within
Smalltalk as only a suggestion- something that an industrious person
could consider as being completely up for grabs.  It's an intriguing
thought to consider a total reconstruction based on the decades
of research, experience, and use of object-oriented systems that has
been accumulated since Smalltalk-80's public release.

-les