The Early History of Smalltalk by Alan Kay

The Early History of Smalltalk

• Most ideas come from previous ideas.
•  Programming languages can be categorized in a number of ways: imperative, applicative, logic-based, problem-oriented, etc. But they all seem to be either an "agglutination of features" or a "crystallization of style".
• It is probably not an accident that the agglutinative languages all seem to have been instigated by committees, and the crystallization languages by a single person.
• Smalltalk's design--and existence--is due to the insight that everything we can describe can be represented by the recursive composition of a single kind of behavioral building block that hides its combination of state and process inside itself and can be dealt with only though the exchange of messages.
• Programming is at heart a practical art in which real things are build, and a real implementation thus has to exist.
• In fact many if not most languages are in use today not because they have any real merits but because of their existence on one or more machines, their ability to be bootstrapped, etc.
• Though OOP came from many motivations, two were central. The large scale one was to find a better module scheme for complex systems involving hiding of details, and the small scale one was to find a more flexible version of assignment, and then to try to eliminate it altogether.
• New ideas go through stages of acceptance, both from within and without. From within, the sequence moves from "barely seeing" a pattern several times, then noting it but not perceiving its "cosmic" significance, then using it operationally in several areas, then comes a "gran rotation" in which the pattern become the center of a new way of thinking, and finally, it turns into the same kind of inflexible religion that it originally broke away from. From without, as Schopenhauer noted, the new idea is first denounced as the work of the insane, in a few years it is considered obvious and mundane, and finally the original denouncers will claim to have invented it.
• The basic principle of recursive design is to make the parts have the same power as the whole.
• Of course, philosophy is about opinion and engineering is about deeds, with science the happy medium somewhere in between.
• An extensional system seemed to be called for in which the end-users would do most of the tailoring (and even some of the direct construction) of their tools.
• One of the basic insights I had gotten from Seymour was that you didn't have to do a lot to make a computer an "object for thought" for children, but what you did had to be done well and be able to apply deeply.
• Point of view is worth 80 IQ points.
• Any tools for children should have great thinking patterns and deep beauty "built-in".
• The best way to predict the future is to invent it. Don't worry about what all those other people might do, this is the century in which almost any clear vision can be made!
• As I mentioned previously, it was annoying that the surface beauty of LISP was marred by some of its key parts having to be introduced as "special forms" rather than as its supposed universal building block of functions. The actual beauty of LISP came more from the promise of its metastructures than its actual model.
• When we turn to the various languages for specifying computations we find many to be general and a few to be parsimonious. For example, we can define universal machine languages in just a few instructions that can specify anything that can be computed. But most of these we would not call beautiful, in part because the amount and kind of code that has to be written to do anything interesting is so contrived and turgid. A simple and small system that can do interesting things also needs a "high slope"--that is a good match between the degree of interestingness and the level of complexity needed to express it.
• You just do it and it's done.
• Main ideas of Smalltalk
• Everything is an object.
• Objects communicate by sending and receiving messages (in terms of objects).
• Objects have their own memory (in terms of objects).
• Every object is an instance of a class (which must be an object).
• The class holds the shared behavior for its instances (in the form of objects in a program list).
• To eval a program list, control is passed to the first object and the remainder is treated as its message.
• Of course, the whole idea of Smalltalk (and OOP in general) is to define everything intentionally.
• It is unfortunate that much of what is called "object-oriented programming" today is simply old style programming with fancier constructs. Many programs are loaded with "assignment-style" operations now done by more expensive attached procedures.
• Where does the special efficiency of object-oriented design come from? This is a good question given that it can be viewed as a slightly different way to apply procedures to data-structures. Part of the effect comes from a much clearer way to represent a complex system. Here, the constraints are as useful as the generalities. Four techniques used together--persistent state, polymorphism, instantiation, and methods-as-goals for the object--account for much of the power. None of these require an "object-oriented" languages to be employed--ALGOL 68 can almost be turned to this style--on OOPL merely focuses the designer's mind in a particular fruitful direction.
• Doing encapsulation right is a commitment not just to abstraction of state, but to eliminate state oriented metaphors from programming.
• Perhaps the most important principle--again derived from operating system architectures--is that when you give someone a structure, rarely do you want them to have unlimited privileges with it.
• In other words, human programmers aren't Turing machines--and the less their programming systems require Turing machine techniques the better.
• You should teach a programming language holistically from working examples of serious programs.
• In part, what we were seeing was the "hacker phenomenon", that, for any given pursuit, a particular 5% of the population will jump into it naturally, while the 80% or so who can learn it in time do not find it at all natural.
• It helps greatly to have some powerful ideas under one's belt to better acquire more powerful ideas.
• It is hard to claim success if only some of the children are successful--and if a maximum effort of both children and teachers was required to get the success to happen. Real pedagogy has to work in much less idealistic settings and be considerably more robust.
• Unfortunately, inheritance--though an incredibly powerful technique--has turned out to be very difficult for novices (and even professional) to deal with.
• The problem is not to get the kids to do stuff--they love to do, even when they are not sure exactly what they are doing. [...] What is difficult is to determine what ideas to put forth and how deeply they should penetrate at a given child's development level.
• When, in what order and depth, and how should the powerful ideas be taught?
• I have met hundreds of programmers in the last 30 years and can see no discernible influence of programming on their general ability to think well or to take an enlightened stance on human knowledge. If anything, the opposite is true. Expert knowledge often remains rooted in the environments in which it was first learned--and most metaphorical extensions result in misleading analogies.
• Tools provide a path, a context, and almost an excuse for developing enlightenment, but no tool ever contained it or can dispense it.
• Cesare Pavese observed: to know the world we must construct it. In other words, we make not just to have, but to know. But the having can happen without most of the knowing taking place.
• Our society has lowered its aims so far that it is happy with "increases in [test] scores" without daring to inquire whether any important threshold has been crossed.
• At the liberal arts level we would expect that connections between each of the fluencies would form truly powerful metaphors for considering ideas in the light of others.
• The reason that many of us want children to understand computing deeply and fluently is that like literature, mathematics, science, music and art, it carries special ways of thinking about situations that in contrast with other knowledge and other ways of thinking critically boost our ability to understand our world.
• Strong paradigms like LISP and Smalltalk are so compelling that they eat their young: when you look at an application in either of these two systems, they resemble the systems themselves, not a new idea.
• Hardware is really just software crystallized early. It is there to make program schemes run as efficiently as possible. But far too often the hardware has been presented as a given and it is up to software designers to make it appear reasonable. This has caused low-level techniques and excessive optimization to hold back progress in program design.
• Systems programmers are high priests of a low cult.
• One way to think about progress in software is that a lot of it has been about finding ways to late-bind, then waging campaigns to convince manufactures to build the ideas into hardware.
• Most machines till have no support for dynamic allocation and garbage collection and so forth. In short, most hardware designs today are just re-optimizations of moribund architectures.
• From the late-binding perspective, OOP can be viewed as a comprehensive technique for late-binding as many things as possible: the mix of state and process in a set of behaviors, where they are located, what they are called, when and why they are invoked, which hardware is used, etc., and more subtle, the strategies used in the OOP scheme itself.
• Again, the whole point of OOP is not to have to worry about what is inside an object.
• Objects made on different machines and with different languages should be able to talk to each other--and will have to in the future.
• A twentieth century problem is that technology has become too "easy". When it was hard to do anything whether good or bad, enough time was taken so that the result was usually good. Now we can make things almost trivially, especially in software, but most of the designs are trivial as well. This is inverse vandalism: the making of things because you can.