Design Principles Behind Smalltalk

http://users.ipa.net/~dwighth/smalltalk/byte_aug81/design_principles_behind_smalltalk.html

Interesting to see the phrases "factoring" and "well-factored system" already in 1981.

I don't know about '81 but when I started programming '86, people were always using terms like 'factoring, well-factored, and even re-factoring. At the time, this was the preferred term to 're-tooling.''

I'll never forget the thrill of reading this article in late 1982.

I just grabbed a copy of this entire issue of BYTE and its just great. It's just as good a read now as it was then.

WONTFIX bug should be reopened.

I just read this for the first time, and the introductory sentence was absolutely startling:

The purpose of the Smalltalk project is to provide computer support for the creative spirit in everyone. -- DanIngalls

This seems an unusual thing for a computer scientist to write in a paper. I'm used to seeing papers about languages talk about efficiency, performance, garbage collection, "compact representations", etc., etc. -- RobertChurch

That is classic DanIngalls, and offers a crisp illustration of the essential difference Smalltalk has for some of us. -- TomStambaugh

It may also provide some insight into why Smalltalk is not the prevalent language for commercial software development. Unfortunately, the creative spirit in everyone is usually irrelevant in that realm. --KrisJohnson

The design principles of Smalltalk, the language:

Every element is an object. Classes, methods, integers, chars, bytecodes, all are objects.
All objects belong to a class that defines their behavior.
All classes belong to a class (its metaclass) that defines the class behavior.

The design principles of Smalltalk, the environment:

The environment is written in Smalltalk and it is interpreted in the environment itself.

Though SmalltalkLanguage is very human-oriented, it does seem to borrow a lot of concepts and terminology and notation from dizzy heights of SetTheory.

Classes are another name for Sets
The Smalltalk class called Object (the class that contains everything) is the SetTheory UniversalSet (the set that contains everything).
A Smalltalk Set is a SetTheory Set.
A Smalltalk OrderedCollection is a SetTheory Ordered Set.
A Smalltalk Association is SetTheory Ordered Pair.
A Smalltalk Dictionary (which is defined in Smalltalk as a collection of Associations) is the same as a SetTheory function (which in SetTheory is defined as a Set of Ordered Pairs).
A Smalltalk BlockClosure? (e.g. [ :x | x > 0 ]) looks a lot like a SetTheory set comprehension (e.g. {x | x > 0}), though BlockClosures? are used for a lot of things other than performing a set comprehension.

There are of course some implementation issues that means that this mapping is not pure.

Classes must form a partial ordering
Clearly you can't change the membership of an object's class once it's created, but you can change what sets it belongs to.
Classes are generally used to define behaviour, sets are used to to define state

--Daniel Poon

I'm not convinced.

Classes are not the same thing as sets. You can think of a class as a particular kind of set, just as you can think of a group or a manifold or any other mathematical object as a particular kind of set, but that isn't very interesting. What Smalltalk calls a Set is indeed a set, but it's more specifically a finite set. (Er, maybe you can subclass Set to get certain kinds of infinite set?) Similarly, Smalltalk's OrderedSet?s and Dictionarys are specifically finite things. A Smalltalk block need not be a predicate. A block can represent any (computable) function, and of course a block can actually do things (i.e., have side effects), which takes us right outside the realm of set theory.

You can say most of what's said above about Smalltalk about plenty of programming languages. All that's really going on, I think, is that some of the concepts set theorists work with (like, er, that of "set") are widely applicable. One exception: I think the decision to say that a Dictionary is a set of associations must have been inspired by the conventions of set theory. -- GarethMcCaughan

You have pointed out many restrictions in the analogy. Indeed, everything in a computer is finite. You could also point out that a Smalltalk Integer is not really an integer, since it is a finite size. Plus blocks do have side effects. My point is that a lot of ideas and notation are borrowed from pure maths.

Contrast this with the early computing languages such as FORTRAN that were used for numerical work, so concepts would have been borrowed from applied maths. For example a function in these languages usually refers to an algorithm, such as computing y=x^2. This is quite a different abstraction to saying a function is a set of associations, wouldn't you say? -- Daniel Poon

Certainly is. But Smalltalk doesn't use the word "function" for its sets of associations. Smalltalk's nearest equivalent of Fortran's functions are the methods, and -- guess what? -- they're (implementations of) algorithms. Smalltalk has more data structures than Fortran, and inevitably some of them look like ones pure mathematicians use. Anyway, this isn't worth arguing about, and I'm sorry if my tone has been too confrontational. I agree that at least one thing in Smalltalk looks like it was inspired by the conventions of set theory (namely, considering mappings as sets of associations). I just don't think the borrowing is all that widespread, and I don't think it makes sense to say "classes are sets, so Smalltalk is borrowing from set theory there". -- GarethMcCaughan

What I find is that when I look at a problem, I divide everything up into sets and functions (in the set theoretic sense of function) and draw a few CommutingDiagrams to clarify the relationships to myself. That mapping all of this onto Smalltalk is then quite easy, Im sure is at least partly coincidence. But I also think some things were put there by design. I guess we will have to wait for a Smalltalk founder to tell us where he/she got the idea for classes and collections -- Daniel Poon.

The paper also offers insights in why subsequently Smalltalk failed to conquer the world. Almost all items in Future Work failed to materialize.

In particular the prediction: "Through the use of microcode, and ultimately hardware, system performance can be improved dramatically without any compromise to the other virtues of the system."

At the time, it would have seemed reasonable, as the idea of a 'stock platform' didn't really exist. High-performance computers of the time were all special-purpose designs such as the CrayOne?, the SuperFoonly?, or the various LispMachine variants; the Alto was actually a typical system of its time in this regard. Even the mainstream systems such as the 370 might have very different hardware for different models of the product line. The small systems of the time were distinctly underpowered, and came in a vast profusion - even the 'standard' systems built around CP/M and the s100 bus were often incompatible with each other. While Moore's Law was already known, it was assumed that it was these sorts of custom systems that would push the speeds along. Also, the most powerful software of the time (Smalltalk and Lisp) required special hardware in the form of tagged memory and so on, and the idea that these lush, elaborate (but very expensive) systems would be abandoned for droves of Unix and MS-DOS/Windows workstations that provided only a small fraction of their capabilities but which could give far superior cost/performance ratios would have been inconceivable. The fact that this is what actually happened was something that could not have been predicted in 1981. - JayOsako

CategoryPaper CategorySmalltalk