Early History Of Smalltalk
Early History Of SmalltalkAlanKay 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
http://www.iam.unibe.ch/~ducasse/FreeBooks/SmalltalkHistoryHOPL.pdf
An easy-to-read version (but many figures omitted) is at
ttp://gagne.homedns.org/%7etgagne/contrib/EarlyHistoryST.html http://propella.sakura.ne.jp/earlyHistoryST/EarlyHistoryST.html
This is also published as a chapter of the book HistoryOfProgrammingLanguagesTwo
See also DesignPrinciplesBehindSmalltalk for DanIngalls' 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 BurnTheDiskpacks. 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 DanIngalls 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 DealersOfLightning.
Question 2 Is this fair comment by Kay? Any connection with Question 1?
In XP terms Q1 is about when to RefactorMercilessly 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 BusinessValueFirst.
I don't think the answers are easy. That's what makes this such a great paper. -- RichardDrake
What I got out of it was more technical. The importance of EvalApply 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 MetaClass 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 SelfLanguage? Kay evidently thinks that classes should be full objects, and instances themselves of classes, and what are they if not metaclasses? -- DaveHarris
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 VisualWorks. The two identical hierarchies of class and metaclass break OnceAndOnlyOnce 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? -- RichardDrake
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. -- DaveHarris
It might be interesting to know that BuddsLittleSmalltalk 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.
RichardDrake 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 BuddsLittleSmalltalk):
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 BuddsLittleSmalltalk) 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.
-- TomStambaugh
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 OnceAndOnlyOnce as I suggest above. Is this what Kay was referring to? How would you rectify this?
In spite of OnceAndOnlyOnce, sometimes parallel structures are at least helpful (at least to my tired brain), even if not "necessary". For example, the FactoryPattern from the GangOfFour 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. -- TomStambaugh
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. -- WardCunningham
In WhatIsWrongWithTheGeneralVisualBasicApproach, it is claimed that most developers found VB's GUI easier to approach, and killed SmallTalk's market share. Any SmallTalk proponents wish to comment on that?
Contains AlanKaysDefinitionOfObjectOriented
Also see MainstreamInfluenceOfFunctionalLanguages.
EditText of this page
(last edited July 12, 2011)
or FindPage with title or text search