## Design Principles Behind Smalltalk

With LtU being 10 years old, it seems appropriate to start recycling ancient underappreciated posts â€” especially those in the static HTML archive where commenting is no longer possible.

With Smalltalk-80 nominally turning 30 and PARC turning 40, 2010 is a fitting year to revisit Design Principles Behind Smalltalk by Daniel H. H. Ingalls, known to his German admirers as Daniel Ha-ha Ingalls.

Mentioned twice by Ehud in 2001 (here and here), Ingalls's piece should be filed under Visionary Languages. Alas, no such category exists on LtU.

## Comment viewing options

### outline

The article at a glance:

Personal Mastery
If a system is to serve the creative spirit, it must be entirely comprehensible to a single individual.
Good Design
A system should be built with a minimum set of unchangeable parts; those parts should be as general as possible; and all parts of the system should be held in a uniform framework.
Purpose of Language
To provide a framework for communication.
Scope
The design of a language for using computers must deal with internal models, external media, and the interaction between these in both the human and the computer.
Objects
A computer language should support the concept of â€œobjectâ€ and provide a uniform means for referring to the objects in its universe.
Storage Management
To be truly â€œobject-orientedâ€, a computer system must provide automatic storage management.

This reminds meâ€¦Â  Aside from C++, are there any other mainstream-ish OOP languages out there that do not provide GC?

On with the principlesâ€¦

Messages
Computing should be viewed as an intrinsic capability of objects that can be uniformly invoked by sending messages.
Uniform Metaphor
A language should be designed around a powerful metaphor that can be uniformly applied in all areas.
Modularity
No component in a complex system should depend on the internal details of any other component.
Classification
A language must provide a means for classifying similar objects, and for adding new classes of objects on equal footing with the kernel classes of the system.
Polymorphism
A program should specify only the behavior of objects, not their representation.
Factoring
Each independent component in a system would appear in only one place.
Leverage
When a system is well factored, great leverage is available to users and implementers alike.
Virtual Machine
A virtual machine specification establishes a framework for the application of technology.
Reactive Principle
Every component accessible to the user should be able to present itself in a meaningful way for observation and manipulation.
Operating System
An operating system is a collection of things that don't fit into a language. There shouldn't be one.
Natural Selection
Languages and systems that are of sound design will persist, to be supplanted only by better ones.

Compare to Some Words of Advice on Language Design.

### other mainstream-ish OOP languages out there that do not provide

Objective-C 1.0 does not, Objective-C 2.0+ has it as optional except on iPhone.

Delphi.

### A "Visionary" department is

A "Visionary" department is a good idea, I must say.

### OO but unmanaged memory.

I think Objective-C has manual memory management.

### A compiler option can enable

A compiler option can enable automatic memory management on OSX. It's still manual on iOS, however.

### Operating systems shouldn't be

Here Daniel Ingalls sounds like Chuck Moore.

I don't think that this principle is standing the test of time well, although maybe it's a projection of another idea, that the machine should be cleanly exposed to the language.

### re: Operating systems shouldn't be

Here Daniel Ingalls sounds like Chuck Moore.

Somewhat, although Moore had a very different notion of what a language should be like and what it should be like to use a computer. For example, Smalltalk had files and directories. Moore might say "why bother? just use raw blocks."

So, speaking of the Ingalls version:

I don't think that this principle is standing the test of time well, [....]

I don't think that the principle has yet been tested by time, but that it is now starting to be, and its prospects are good:

### Lively Kernel

Re: comment-62084:

We're not far from a circumstance wherein a personal computer can get by running absolutely nothing at all other than a web browser that supports javascript.

A veiled reference to the latest project that Ingalls has been working on?

### The veil you are lifting

is probably not Thomas's princess.

Thomas Lord has been working on his own sort of Lively Kernel project for years now. He posted a design document for it on LtU a few years ago, but it has been taken down. It was codenamed Flower.

### Small correction

Similarly, bang for buck-wise, early unix workstations soundly beat late lisp machines. It started to become apparent that lisp performance could be somewhat OK (for some purposes) on "stock hardware", especially if it isn't charged with replacing the OS, and again: hardware constraints pushed a C kernel underneath lisp.

Actually, early workstations soundly beat late lisp machines in spite of the presence of a C kernel. Several things converged at more or less the same time:

• a set of compilation, runtime, and GC techniques emerged that didn't favor tagged arithmetic
• the reliance on non-commodity memory word sizes caught up with the various lisp machine implementations
• Register allocation techniques improved, making the memory-memory architectures of the custom lisp engines progressively slower on a relative basis.

So what's actually surprising is that the introduction of a user/supervisor privilege separation, with the data motion costs that this entailed in the architectures of the day, didn't buy the custom machines another generation of life. But it didn't: the impact of register allocation and commodity memory (and therefore DMA) was that significant.

### not how I recall it.

That's not how I recall it.

Non-lisp hardware, as I recall it, revved faster and could win some highly selective benchmarks but tagged architectures were by no means the losers other than being less funded to rev as quickly.

But it didn't: the impact of register allocation and commodity memory (and therefore DMA) was that significant.

I wouldn't quite put it that way. Prbly the wrong thread to hash it out at length though, if we're to stay in the neighborhood of topic? Commodity everything was the economic thing that dominated -- CPU, Memory, bus interface, ... which ones were picked was not so much narrowly tied to register allocation and DMA.

### languages should provide os-like abstractions

I was thinking about your comment this morning, and came to a similar conclusion as Tom did -- that perhaps Ingalls was right in the sense of the language becoming the new operating system.

Of course with some library abstractions one can make a program oblivious to running on Windows or Unix, but I think the point goes deeper: that one should be able to implement abstractions in a language that look like operating system abstractions.

Specifically, I'm thinking of Kiselyov and Shan's Delimited continuations in operating systems.

This paper is very on topic here: Programming Languages as Operating Systems.

### what language-as-os means to me

I understand "language as OS" to mean two things:

First, just as you say, OS features should be presented within the languages abstractions.

Second, is to have most of the environment (OS features and all) actually written in the language, in a portable way (like Smalltalk-80).

For example:

a) does your language offer a good "explanation" for asynchronous I/O? (Are the abstractions good?)

b) can you reasonably code a network stack, and a file system or other data base storage manager in it? (Is it fast enough?)

The smaller, simpler, and "cleaner" you can make the non-portable core part of the run-time system, the greater the liberties you likely afford yourself to run on non-standard hardware or in non-standard environments.

### the Forth approach to operating systems

Re: comment-62077: â€œâ€¦Daniel Ingalls sounds like Chuck Moore.â€

Turns out, this observation has been made before. The most promising Google hit on this topic seems to be The FORTH Approach to Operating Systems (1976) by Elizabeth D. Rather and Charles H. Moore. To lift a quote:

In 1973, Koudela (The Past, Present, and Future of Minicomputers: A Scenario) listed several desirable features of minicomputer software which can simplify the programmer's task:

• Integration of system functions such as language processors, operating systems, utilities (e.g. for editing and debugging) and libraries into a single package through which the user can conversationally interact with the hardware;
• Programmer interaction with source language only;
• Transparent (to the user) translation of the source to machine language for high speed execution;

• Ability to modify or extend such a system easily for specific applications.

FORTH is such a system, including in a single, integrated structure an interactive hlgh-level language, macro assembler, multlprogrammed OS and utilities, plus some other concepts such as reverse Polish Notation, stack organization and virtual memory for data storage.

Previously on LtU:

### Mea Culpa

Turns out, this observation has been made before — I strongly suspect subconscious plagiarism...

I interpret these comments as an ideal of personal computing where every "user" becomes instead a master of their computing environment, i.e., a programmer/user. I would include Ted Nelson's "Computer Lib" philosophy in the same camp.

I still believe it's a beautiful and empowering ideal worth pursuing and promoting, although the current movement of computing to "the grid" far beyond individuals' detailed understanding and control is, by this criteria, many steps in opposite, "wrong" direction.

### Isn't that from the issue w/the hot-air balloon on the cover?

I still have that issue somewhere...
That article inspired that same year to try and write a Smalltalk for the TRS-80 in assembler - quite a project that was never finished. It's not the bytecode interepreter or the parser that was necessarily the hard part - it was getting a VM in the "magic" state w/o any bootstrapping, including all attendant pre-existing instances, classes, meta-classes, etc., and all the relationships between them that were necessary before life could be breathed into the system for the first time. (Never mind that w/just the assember and 48K of RAM, it wasn't going to be easy, if even possible.) I could have tried it in C, but at the time, working with the C compiler (even on the newly released PC) meant running cpp, cc0, & cc1 seperately - and swapping floppy discs each time! I gave up on it, and did end up writing a FORTH and a Lisp, which took less time together then I'd spend just w/the prelimnaries for the ST.

### BYTE Magazine, August 1981

Re: comment-62083: I still have that issue somewhereâ€¦

The hot-air balloon cover is reportedly by Robert Tinney. Scan it before it turns to dust.

### shark-infested waters

Turns out, somebody did scan it already: Byte_1981_08_150dpi.pdf, 85MB, 171 pages, scanned in color at 150DPI. In Introducing the Smalltalk-80 System, Adele Goldberg gives us the scoop on the drawing of the cover:

The [Aug '78] issue was a special on the language Pascal, so [then editor Carl Helmers] took the opportunity to present Pascal's triangle as drawn by artist Robert Tinney. The primary allegory of the cover was the inversion of the Bermuda Triangle myth to show smooth waters within the area labeled â€œPascals Triangle.â€ In explaining the allegory, Helmers guided the traveler through the FORTRAN Ocean, the BASIC Sea, around the Isle of BAL, and up the Land of Smalltalk:

Traveling upward (in the picture) through heavy seas we come to the pinnacle, a snow white island rising like an ivory tower out of the surrounding shark infested waters. Here we find the fantastic kingdom of Smalltalk, where great and magical things happen. But alas â€¦ the craggy aloofness of the kingdom of Smalltalk keeps it out the mainstream of things.

This month's cover â€¦ depicts the clouds clearing from around the kingdom of Smalltalk, and, with banners streaming, the Smalltalk system is taking flight in the mainstream of computer programming community. This cover was also executed by Robert Tinneyâ€¦

â€¦ in 1981, it was Smalltalk's turn to be featured on the cover of BYTE. Carl told me that since the Smalltalk developers had taken good-natured â€œoffenseâ€ at their representation in the previous cover, this time they wanted Smalltalk to be shown at the moment of liberation from the ivory tower. I'm not positive, but I think it was the Smalltalk team itself who came up with the idea of using the image of a balloon. Anyway, I painted the same cliffs and ivory tower from the previous cover, only this time they are being left far below as Smalltalk escapes its cloistered image and ascends to the heights of popular appeal!

What's BAL?

### Visionary languages

I also agree that a department on visionary languages would be a good thing. I'd add Forth, APL, and Lisp to the list along with Smalltalk.

### certifiably visionary Alan Kay

Re: comment-62089: â€¦ a department on visionary languages would be a good thing.

A Conversation with Alan Kay (ACM Queue vol. 2, no. 9, Dec/Jan 2004-05, PDF) comes highly recommended by a member of Queue's Editorial Advisory Board, Bryan Cantrill:

I read a few of the articles. I found them to be surprisingly useful â€” almost embarrassingly so. I sheepishly subscribed, and I found that even the articles that I disagreed with â€” like this interview with an apparently insane Alan Kay â€” were more thought-provoking than enraging.

The interview was conducted by Stuart Feldman, the original author of make, who is of the opinion that

â€¦ we have one big language and one smaller language every decade â€” that appears to be all the field can afford. Smalltalk is one of those five- or 10-year events.

Alan Kay says that Smalltalk is dead:

Perhaps it was commercialization in the 1980s that killed off the next expected new thing. Our plan and our hope was that the next generation of kids would come along and do something better than Smalltalk around 1984 or so.

â€¦I would compare the Smalltalk stuff that we did in the â€™70s with something like a Gothic cathedral. We had two ideas, really. One of them we got from Lisp: late binding. The other one was the idea of objects. Those gave us something a little bit like the (ogival) arch, so we were able to make complex, seemingly large structures out of very little material, but I wouldnâ€™t put us much past the engineering of 1,000 years ago.

â€¦actually both Lisp and Smalltalk were done in by the eight-bit microprocessorâ€”itâ€™s not because theyâ€™re eight-bit micros, itâ€™s because the processor architectures were bad, and they just killed the dynamic languages. Today these languages run reasonably because even though the architectures are still bad, the level 2 caches are so large that some fraction of the things that need to work, work reasonably well inside the caches; so both Lisp and Smalltalk can do their things and are viable today. But both of them are quite obsolete, of course.

Itâ€™s well known that I tried to kill Smalltalk in the later â€™70s.

â€¦the problem isâ€”Iâ€™ve said this about both Smalltalk and Lispâ€”they tend to eat their young. What I mean is that both Lisp and Smalltalk are really fabulous vehicles, because they have a meta-system. They have so many ways of dealing with problems that the early-binding languages donâ€™t have, that itâ€™s very, very difficult for people who like Lisp or Smalltalk to imagine anything else.

Basically what happened is this vehicle became more and more a programmerâ€™s vehicle and less and less a childrenâ€™s vehicleâ€”the version that got put out, Smalltalk â€™80, I donâ€™t think it was ever programmed by a child. I donâ€™t think it could have been programmed by a child because it had lost some of its amenities, even as it gained pragmatic power. So the death of Smalltalk in a way came as soon as it got recognized by real programmers as being something useful; they made it into more of their own image, and it started losing its nice end-user features.

Long live Squeak.

Perhaps, I should've just linked to the earlier discussion.

### beyond Smalltalk

Re: comment-62482: â€œAlan Kay says that Smalltalk is dead.â€

In a comment on the The Myths of Object Orientation, Z-Bo quoted from an old post by Alan Kay on the Squeak mailing list:

â€¦ whereas at PARC we changed Smalltalk constantly, treating it always as a work in progress â€” when ST hit the larger world, it was pretty much taken as â€œsomething just to be learned,â€ as though it were Pascal or Algol. Smalltalk-80 never really was mutated into the next better versions of OOP. Given the current low state of programming in general, I think this is a real mistake.

I would suggest that more progress could be made if the smart and talented â€¦ would think more about what the next step in metaprogramming should be â€” how can we get great power, parsimony, AND security of meaning?

Note to self: Kay's post is part of a larger thread on prototypes vs. classes initiated by Steve Dekorte and extended by Patrick Logan, David N. Smith, and Dan Ingalls, among others.

### future work

The same issue also features an introduction to The Smalltalk Environment by Larry Don't-Mode-Me-In Tesler who, as you recall, was a major influence on Vassili Bykov's work on Hopscotch. Tesler writes:

Most compilers can generate more efficient object code if types are declared. Existing implementations of Smalltalk cannot take advantage of type declarations. We expect that future versions will have that ability. At that time, type declarations may be added to the language. They probably will be supplied by the system rather the user, using a program-analysis technique called â€œtype inference.â€

Seems like Bracha has fulfilled some parts of this program. (Strongtalk and mixins in Newspeak come to mind.) Now that Ingalls and Bracha both work at SAP Labs (seemingly a place where many contrarian minds have found refuge) interesting things may come out of their occasional chats by the water cooler.