BYTE Magazine, August 1981. (c) by The McGraw-Hill Companies, Inc., NY.
Copied from users.ipa.net 
wayback
Scanned in and converted to HTML (with recreated graphics) by Dwight Hughes. page
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.
-- Dan Ingalls
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. -- Robert Church
That is classic Dan Ingalls, and offers a crisp illustration of the essential difference Smalltalk has for some of us. -- Tom Stambaugh
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. --Kris Johnson
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 Smalltalk Language is very human-oriented, it does seem to borrow a lot of concepts and terminology and notation from dizzy heights of Set Theory.
Classes are another name for Sets
The Smalltalk class called Object (the class that contains everything) is the Set Theory Universal Set (the set that contains everything).
A Smalltalk Set is a Set Theory Set.
A Smalltalk Ordered Collection is a Set Theory Ordered Set.
A Smalltalk Association is Set Theory Ordered Pair.
A Smalltalk Dictionary (which is defined in Smalltalk as a collection of Associations) is the same as a Set Theory function (which in Set Theory is defined as a Set of Ordered Pairs).
A Smalltalk Block Closure (e.g. [ :x | x > 0 ]) looks a lot like a Set Theory set comprehension (e.g. {x | x > 0}), though Block Closures 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 Ordered Sets 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. -- Gareth Mc Caughan
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". -- Gareth Mc Caughan
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 Commuting Diagrams 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 Cray One, the Super Foonly, or the various Lisp Machine 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. - Jay Osako
See original on c2.com