How did people write end-user software in Smalltalk?

Question

There is something I've never understood about Smalltalk, since reading about it in a book when I was a child, tho' I have never used it "in anger". I know that it is turtles-all-the-way-down, that you can break into the program at any time, inspect the state of your objects, even change the code, and resume running. This is obviously a dream come true for a researcher, whether in CS or in industry, an engineer simulating a system, an analyst modelling a market, and so on. I also know that there was no concept of writing source in text files and compiling them into a binary, the editor and the runtime are the same thing. But how do you deliver software to an end user who wouldn't know a debugger if it bit them on the nose, and couldn't care less what an object is? Was there a secret keystroke to turn all those features off and make it behave like "normal" software? Or was Smalltalk software only ever sold to sophisticated users who were programmers too?

Answer 1

Or was Smalltalk software only ever sold to sophisticated users who were programmers too?

No. It's the other way around: Smalltalk was designed so that every user can be a programmer, without needing to be sophisticated. In fact, Smalltalk was designed for children.

The basic idea is that a user would read a manual about the length of a middle-sized undergrad college textbook in order to use sophisticated machinery. Say, you are a carpenter and buy a CNC machine, you wouldn't expect to be able to use it right away, but you also wouldn't expect to need years to learn how to use it. You would probably expect to read about 10000 to 100000 lines of manual and learn about a couple of days to a couple of weeks.

For a software system, the ultimate manual is the source code. So, in order to be usable, the software system should consist of no more than 100000 lines of code, so that the user can read all of them. (And it should be written in such a way and such a language that she can understand it.) That's the goal of Smalltalk: the original Smalltalk system was about 60000 lines of code for everything, the "OS", the hardware drivers, the VM, the compiler, the interpreter, the IDE, the debugger, the editor, an office suite, a distributed document management system, etc. In the 1970s, that was the best they could do, today, 40 years later, we have much better languages available, and the replacement system and language(s) that Alan Kay's team are working on currently, is expected to be less than 20000 lines for the same feature set. (Compare that to e.g. Windows, which has 50 million lines.)

That was the idea. How well that idea worked, well … judge for yourself :-)

Modern Smalltalks try to make a distinction between development and deployment. Basically, you define some application root object, the system traces the connections between all objects in the system, and copies out only those objects which are directly or indirectly connected to the root application object, leaving you with a streamlined image that contains only the application and the libraries and frameworks needed by it.

You typically also don't edit the running system directly, but use some kind of version control system (e.g. Monticello) that stores your modifications as a series of semantic changes to the system and thus can be replayed on a different system. There is also research into module systems and package management systems, and most modern Smalltalks have at least one of the two.

So, the way that Smalltalk systems are deployed today is that there is some minimal "clean" image, and you apply CVS changesets or install packages or link modules on top of that, which yields an image which is specialized just for that application. If you want to do development, you start with a development image which includes the editor, compiler, IDE, etc. and apply those same changes on top of that.

The languages that came after Smalltalk (e.g. Self, Newspeak) often included a textual serialization format for code (Smalltalk itself doesn't have syntax for classes or methods, because they are created programmatically by the IDE (e.g. creating a class is actually just calling the subclass method on some class which will return a class which is a subclass of the class the method was called on); it only has syntax for expressions and statements.), that could be used to "file in" classes and methods into the system, and modern Smalltalks also have that capability.

Answer 2

One point that Jörg did not mention in his answer: After the "deployment" step it is actually hard to tell that an application was written in Smalltalk, because the IDE was either stripped out or hidden. For example, try these:

http://scratch.mit.edu/scratch_1.4/

http://www.planet-plopp.com/english/download.html

Also, just by looking at the range of applications built with Smalltalk, you can tell that their users are certainly no programmers nowadays: https://twitter.com/hashtag/thingsPeopleBuiltWithSmalltalk

That every user should be able to modify their software is a Smalltalk idea that still has not made it to the mainstream (while many other of its ideas are commonplace nowadays - like GUIs or Object-Orientation).

Answer 3

In the classic Smalltalk-80, there was a SystemTracer that we at Tektronix used to "strip" an image for deployment.

Basically, it performed a full traversal of the system from a single specified point, excluding the global SystemDictionary and its contents.

This way, you could run SystemTracer on your application (typically, a Contoller subclass), and it would drag everything else in with it, but not stuff like Context or other classes and distinguished objects that were not involved in the operation of your application.