Alan Kay clarifies much of the folklore, at least from his own point of view...
The Early History of Smalltalk Alan C. Kay
ACM SIGPLAN Notices Volume 28, No. 3, March 1993 Pages 69-95.
A somewhat hard-to-read PDF of this paper is available at
An easy-to-read version (but many figures omitted) is at
ttp://gagne.homedns.org/%7etgagne/contrib/EarlyHistoryST.html
propella.sakura.ne.jp 
This is also published as a chapter of the book History Of Programming Languages Two
See also Design Principles Behind Smalltalk for Dan Ingalls' brilliant summary in 1981.
Two questions
Two immediate and not unrelated questions stick out for me from reading Alan's account for the first time:
[Section 11.5] In January 1976 Kay took the Smalltalk team away with a view to Burn The Diskpacks. He used the "old aphorism" that "no biological organism can live in its own waste products" in arguing that a radical restart was needed for the Learning Research Group to make progress with his ultimate goals. But instead a compromise, more evolutionary approach was taken, continuing to take advantage of Dan Ingalls wonderful implementation skills. The "waste products" turned into Smalltalk-80, which had considerable influence on some (I think many of the best) Wiki thinkers on software.
Question 1 Was Kay right, what were the consequences of what actually happened and what are the lessons from this key project decision point?
[Appendix VI] Under Historical Views of PARC and LRG Kay's last entry is
"19** Fumbling the Future, disorganized, and inaccurate portrait of PARC"
But also the only portrait quoted written by business people (both MBAs if I remember) who were trying to make sense of why Xerox never made any money from the software and hardware innovations at PARC. -- By now there's also Dealers Of Lightning.
Question 2 Is this fair comment by Kay? Any connection with Question 1?
In XP terms Q1 is about when to Refactor Mercilessly and when to throw years of source code away and start again. Note that XP only began at C3 because a CIO was willing to take the second option. Q2 is about how all the very best XP practices (which many of us first got a feel for using Smalltalk) can reliably be made to relate, over many years, to the guiding principle Business Value First.
I don't think the answers are easy. That's what makes this such a great paper. -- Richard Drake
What I got out of it was more technical. The importance of Eval Apply loops for one thing.
Another is that it confirmed a rumour that the early Smalltalks gave more control to the receiver of a message than currently. Almost as if each object were a little parser, defining its local language on the fly. This turned out to be too much flexibility. The current compromise of unary, operator and keyword messages is, for me, one of the most beautiful things (even when compared to Lisp).
On the other hand, Kay seems to think that the current Meta Class system was a mistake. I have heard this before, from other people, but I'm not sure what the alternative is. Is it prototypes, as in the Self Language? Kay evidently thinks that classes should be full objects, and instances themselves of classes, and what are they if not metaclasses? -- Dave Harris
I'm sure Kay is right on this last point. At least we could never find anything useful to do with the metaclass hierarchy in Visual Works. The two identical hierarchies of class and metaclass break Once And Only Once and have been shown to be cumbersome and unnecessary by later systems haven't they? Each class should be an instance of Class, which is an instance of itself, n'est-ce pas? Any experts still out there? -- Richard Drake
Does that mean we can't have class-specific class methods? If an instances methods are also available to other instances of the same class, then adding a method to, for example, String class would make it available to Integer class, because both are instances of the same class, namely Class.
Or does it mean that method-lookup is different for classes to normal instances? In implementation terms, methods of String are stored with String class, and methods of String class would also be stored with String class. (Currently they are stored with String class class.)
All 3 approaches are not especially nice, but the current approach seems more uniform. -- Dave Harris
It might be interesting to know that Budds Little Smalltalk doesn't have a metaclass hierarchy (i.e. classes are just instanced of Class). The most common task of the class object, creating instances, is replaced by something like Java's constructors.
Richard Drake said "At least we could never find anything useful to do with the metaclass hierarchy" -- speaking in hyperbole, I hope.
Here are some things I do, trivially, that use the metaclass hierarchy in Smalltalk-80 and are difficult or nearly impossible to do in Java (with all due respect to Budds Little Smalltalk):
Easy singletons that descend from a common parent (use a class instance variable to hold the singleton)
Straightforward Factory Pattern implementation, built on the class side and using the Template Method Pattern.
Straightforward query string and SQL generation for classes that contain DB elements.
Easy and obvious maps for classes that do uniqueing on their instances
Straightforward implementations for default values, optional arguments, runtime configuration, and so on.
This list does not include some of the more subtle situations where I've found the very existence of the metaclass hierarchy make a difficult problem possible.
I don't doubt that we could make a better metastructure - there are changes I'd like to see, too. After all, this approach is twenty years old. I somehow doubt that Kay would suggest that an environment have *no* metastructure. Extensions, improvements, even replacement - yes. Remove it? No.
By the way, the current implementation of Java (and apparently also Budds Little Smalltalk) offers essentially the semantics of Smalltalk-78, in which there was a single class "Class", and every class was an instance of Class. The difficulty with this approach, as every Java developer has discovered, is that class-specific behavior - especially initialization - is precluded, as are class instance variables.
You've got me worried enough Tom to want to modify my statement to "At least I never knowingly found anything useful to do with the metaclass hierarchy, as far as I can remember". I was probably benefiting when I wrote Smalltalk and I'm sure that those that wrote more Smalltalk than me might want to be left out of the statement. However ... the duplicate class hierarchy always struck me as ugly and unnecessary. Doesn't it break Once And Only Once as I suggest above. Is this what Kay was referring to? How would you rectify this?
In spite of Once And Only Once, sometimes parallel structures are at least helpful (at least to my tired brain), even if not "necessary". For example, the Factory Pattern from the Gang Of Four outlines the basic theme behind the Smalltalk metaclass structure. I don't know what Alan was referring to - so I'm not sure what to rectify. The folks at Digitalk did some interesting stuff with instance-specific methods, where they hung the method dictionary from each object and then referenced the class object from there. Perhaps some variant of that might allow a simplification of the dual-rail metaclass hierarchy. This is one of those questions that I'd love to look at more closely someday, but so far haven't been able to fund. -- Tom Stambaugh
One real benefit of the parallel class-metaclass hierarchy was that it added meta capability to classes without adding any additional complexity to the virtual machine. VMs are so complex now that this would hardly be noticed, but it was significant in Smalltalk. -- Ward Cunningham
In What Is Wrong With The General Visual Basic Approach, it is claimed that most developers found VB's GUI easier to approach, and killed Small Talk's market share. Any Small Talk proponents wish to comment on that?
See original on c2.com