|
|
Research Scientist. Principal member of the team under Dr. Alan Kay working on Squeak software for the Hundred Dollar Laptop computer.
Tweak is a variant of Smalltalk by Andreas Raab that is extremely folded and factored. Under HP Fellow Alan Kay, I built an automatic explanation facility for the Tweak end-user programming environment. The user builds an object with the user interface. When he chooses "How to Build This", it automatically generate an English explanation of how to do it, the code to construct it, and the user interface steps to build it.
I designed and built an application with an innovative user interface for specifying finite state machines (FSMs). Sadly, the interesting technical details cannot be disclosed.
Squeak is an innovative professional programming system, begun and coordinated by the Squeak Central group, and supported by an enthusiastic open source community. Squeak is a variety of Smalltalk. It contains the eToy system, where kids can build and program their own on-screen toys and school projects. As a core member of the team since its inception, I designed and built many aspects of it. (Work done at Apple Computer in 1996, Disney Imagineering 1996-2001, and Viewpoints Research 2001, all under Alan Kay.)
At the beginning of the Squeak project in 1996, I built the storage manager and garbage collector. I was in charge of converting the objects in Apple Smalltalk to the Squeak object format to project the seminal 'image'. (The original Squeak implementation team was Dan Ingalls, myself, John Maloney, and Scott Wallace. We were soon joined by Andreas Raab.)
|
|
|
One of the first things we needed at Disney was a painting system for kids. A Disney artist drew the look of the Squeak PaintBox, and I wrote the code that makes it work.
EToys are simple construction kits for kids that teach programming. A child follows instructions and is able to build his own interactive toy in a few minutes. I built pilot versions of many EToys, and wrote code to support specific features in EToys. (Scott Wallace is the principal author of EToys environment, under the guidance of Alan Kay.) (No relation to the company called eToys.com.)
We experimented with many ways to express scripts in EToys. Kids start out by dragging tiles from a Viewer. We wanted a smooth transition to manipulating tokens, and eventually letting the child write scripts in free text. I built this experiment called uni-tiles. The borders around the syntactical units can be faded out to show the script in plain text.
For years we talked about the algorithm that computes line breaks in text. It is symbolic of a threshhold in program difficulty. If an ordinary person could understand that algorithm in EToys, it would be a breakthrough. Inspired by Mitch Resnick and Brian Silverman's StarLogo, I told each individual letter how to follow the letter in front of it. A letter discovers when it begins a word that hangs over the end of the line, and travels over to start a new line. Watching the Wandering Letters algorithm in action is quite amusing.
Scott Wallace and I built the original Method Finder for Squeak. It allows the user to type in any fragment of a message name, and see a list of all the subroutines in the system that have the fragment in their name. In 1999 I could not resist adding search by example to the Method Finder. Suppose that you are new to Squeak and you want to copy a string with every occurance of a specific letter removed. There probably already is a method that does this, but you don't know it's name. The top pane in the illustration shows what to enter into the Method Finder. The string 'knock knock' and the character $k are the inputs. 'noc noc' is the answer you want the method to return. The Method Finder finds "copyWithout:". It does this even though "copyWithout:" takes a string as an argument, and the example has a character.
The Method Finder works by blindly executing 850 of the most common methods in Squeak. It uses the example objects supplied by the user. It tries all permutations of the receiver and arguments, since the user can't be expected to know the proper order. All errors are caught and suppressed, and the search runs quickly.
The members of Squeak Central were spread out over several states, and we needed to merge our changes into a single version of Squeak. To fill this need, I designed and built the update mechanism. As a maintainer of Squeak finishes a new feature or bug fix, the update mechanism gives it a serial number and sends it to a server. When another member of the team is in a stable state, and wants to update, he asks for updates from the server. Files are processed on the user's machine in the same order that they were created in. Each has a very high chance of working, since the user's machine is in substantially the same state as the author's machine.
The update mechanism was an indispensable part of the process we used to build the Squeak system. It served us much better than a then-popular heavyweight source control system could. After staying up until 2 am to finish a new feature, it is very satisfying to put it out as an update. You fall into bed knowing that other users of the system will download and install your feature just in the course of fetching updates. You don't have to fret or spend any effort to make sure it gets to other people's machines.
For ten years, I have built, maintained, and extended the way that Squeak exports objects for permanent storage. SmartReferenceStream is the class that does this. Its main use is to store on the disk an entire screen full of objects, such as an EToy. An important feature of SmartReferenceStream is how it deals with the addition or deletion of instance variables. For every object that is stored, there is an entry for its class. The names of the class's instance variables, and their order are stored in the file as text. When an object file is loaded into a new system, the list of instance variables is compared with that class's current shape. Any changes are mapped, and the data in the fields of the class's instances are moved around. Classes that have been renamed or subsumed by another class are also handled. This remapping has greatly extended the usefulness of object files. We routinely load and run projects that come from other versions of Squeak, both older and younger than the user's version.
I also built the original FTP client in Squeak, extended the project switching mechanism that allows multiple screens full of windows, and am one of the people who fixes bugs all over the system.
A Swiki is a Squeak-based version of Ward Cunningham's WikiWikiWeb. Any person who views a Wiki can click the edit button, and edit the contents of the page. Wikis are very useful for cooperating groups of people, such as students in a class. Mark Guzdial and a student at Georgia Tech built an in-memory Wiki in Squeak. I designed and built persistant storage for the pages, that retains all old versions. The success of the Swiki led a group of students to start a company and market a commercial version named Comanche.
I built and maintained the original Squeak.org website.
|
Along with Jim Spohrer and Alan Kay, I authored the Squeak Open Source License from Apple. It allows commercial systems to be created in Squeak and sold royalty-free. Approved by Apple in 1996, this was one of the first open source licenses, and one of the first approved by a company that did not have open source as its business model.
An Active Essay is an online article that contains a live simulation. I designed, wrote, and constructed this essay that demonstrates biological evolution using Richard Dawkins' example of evolving a sentence. Key parts of the program for the simulation are shown in the article. The code in the article is 'live'. Readers can change the code and see what happens in the simulation. They are able to learn about complex interactions more easily, because they can make changes and see the effects. At Alan Kay's urging, I have built Active Essays in HyperCard, on web pages with a Glyphic Codeworks plug-in, and as a loadable project in Squeak.
Designed and built Steel Trap, a program that attempts to write code fragments by looking at examples. It did some impressive things, like discover If-Then-Elses for non-obvious examples. A complex tree of guard clauses to avoid errors handicapped this program. Steel Trap served as the basis for my later Method Finder in Squeak.
I was chief advisor to author Bill Atkinson during his creation of HyperCard at Apple. The card above is from the Help System, authored by my first wife, Carol. The Help System was the most complex application written in HyperCard during development, and it drove many design decisions. HyperCard is a very flexible system, allowing a wide range of people to create their own applications. It was the first of a category of end user programmable systems, such as Visual Basic.
In the Fall of 1985, the protype of Hypercard, called WildCard, held all of its stacks in a single large file. Work on the Help System told us that a stack needed to have more than one background (kind of card) in it. Bill Atkinson estimated that adding multiple backgrounds would take six months, and was really dreading doing it. One day I realized that if Bill simply called each 'stack' in the big file a 'background', and added some simple code to load a new file when changing stacks, he would have multiple backgrounds. During an outdoor birthday party, I drew pictures on a napkin to explain my proposal. Bill got very excited, and two days later multiple backgrounds were working.
Xerox's release of Smalltalk-80 was an important event. I helped prepare the system for release. Among many items I worked on, was writing the comments for all of the methods that are system primitives. 1981.
I concieved and built the Explain feature in Smalltalk-80. It allows a user to select any variable or punctuation in Smalltalk code, and get an explanation of what it is. Explanations often contain executable code fragments that allow the user to see the uses of an instance variable, or the implementors of a message. 1981. (Inspired by Ellis Cohen's frustration when he was learning Smalltalk.)
Wrote the book, A Taste of Smalltalk with Dave Patterson, an introduction to Smalltalk (W.W. Norton, 1986).
Large Object-Oriented Memory (LOOM) is an object swapping system with 16-bit wide objects in memory, and 32-bit wide objects on the disk. Every field of every object is converted as it is swapped in or out. An object is assigned a different short address for each distinct trip into main memory. LOOM was not fast enough to be used widely, but was an interesting engineering feat. Simulation in Smalltalk, implemented in BCPL and Dorado microcode on the Dorado, 1976-1985. Concieved, designed, and implemented by Ted, with implementation help from Glenn Krasner.
I was one of the four programmers, with Dan Ingalls, Dave Robson, and Diana Merry, who constructed Smalltalk-76. I was responsible for the object format, the storage manager, the OOZE virtual memory, and writing the initial object file. Co-authored and ran the System Tracer, which converted the entire system from one object format to another. Alto machine code on the Alto, 1976-77.
I implemented OOZE, the first purely object-oriented virtual memory. It allowed 64K objects to exist in a 16 bit address space on a 16-bit machine. It swapped 160k bytes of objects on the disk into 40k bytes in memory. This system worked very well and supported Smalltalk-74 and then Smalltalk-76. OOZE underpinned the Smalltalk the introduced overlapping windows to the world in Alan Kay's September 1977 Scientific American article. It also allowed enough objects for Danny Bobrow and Ira Goldstein to build PIE, an important system in which the same object has many facets. OOZE (Object-Oriented Zoned Environment) is explained in my article "Virtual Memory for an Object-Oriented Langauge", Byte Magazine, August 1981. Alto machine code on the Alto, 1975-76. (Idea by Dan Ingalls and Ted.)
Full crash recovery in OOZE used a "clock algorithm" to checkpoint Smalltalk on the disk after every few kilobytes of object swaps. This gave a checkpoint about every three minutes. If Smalltalk crashed, it would resume from the checkpoint, restoring the user to exactly where he or she was a minute or two before. This was a vital part of Smalltalk, since the Alto hardware crashed several times a day, and since Smalltalk was saved and resaved as a core image, rather being built from source files. Alto machine code on the Alto, 1975-76. (Idea by Ted. Special inspiration from Alan Kay, who said that it would not work!)
This is a Painting system I did for Smalltalk-72. The interesting part is that the paint tools (the icons down the side) are each composed from a brush size, a bit-interaction mode, a pen movement style, and an ink pattern. Composable tools did not show up in other painting systems until much later. Alto, 1975 (Idea by Ted. The painting system is based on one by Alan Borning and on the paint box by Bob Flegal and Bill Bowman.)
The paint tools, and the other groups of buttons on the screen, have the property that only one button in the group is selected at any one time. There was no class in Smalltalk to do this, so I wrote one. I tried to think of a descriptive name, and remembered the push buttons on a car radio. I named the class RadioButtons, thus coining a term that became ubiquitous, and remains, in the vocabulary of user interface nomenclature across most or all operating systems.
Implemented the first Realtime FM Music Timbre Editor (TWANG) for Smaltalk-72. Built in Smalltalk on the Alto, 1975. (Idea by Alan Kay and John Chowning, realtime FM sound synthesis microcode by Steve Saunders)
Implemented a realtime Player Piano Roll representation of music as part of Smalltalk-72 in the summer of 1973. It showed music as it was played, and was also an editor that allowed note values to be changed, the score to be stretched or compressed, and pieces of it rearranged. No special hardware supported the music synthesis or the note display. The only hardware modification was to map keys on the external music keyboard to bits in memory. In Alto machine code on the Alto, 1973. (Idea by Alan Kay)
As Smalltalk-72 was first being written for the Data General Nova by Dan Ingalls, I wrote the machine code to display Turtle graphics. This code was carried over to Smalltalk-72 on the Alto. Dec 1972.