Previous | Table of Contents | Next |
Like the last version of Smalltalk-72, the Smalltalk-76 system supported overlapping windows. Ingalls had produced an early version of code browsing, which was essentially an editing window open on a file containing the textual representation of a class and providing the ability to (re)compile the full class. Larry Tesler produced the first code browsers with subviews as a structured way to examine a class. His method views let the programmer call on the compiler to compile just one method at a time. These programming tools introduced a new interactive and incremental approach to software development. The tools were based on three ideas: display the structure of the software (parts and relations), provide techniques for asking questions about that structure, and handle an incremental cycle for edit-compile-test at the method level. A browser displays the class description in terms of attribute structure, the message interface, and the methods that implement messages. An inspector displays the current values of an instances attributes. A debuggerwhich really serves as a process inspectordisplays the sequence of message sends interrupted once an exception occurs. Browsers, inspectors, and debuggers do more than display the descriptions and current values; they allow the user to change methods and values in the middle of an execution and then continue.
When programmers started writing class descriptions in these browsers, a new era of design began. The average size of a method tended to correspond to the screen space available for typing the method text (which consisted of around seven message expressions in addition to the method header information).6 Software evolved (actually it felt like software was molded like clay). The programmer could write a partial class description, create an instance to try out its partial capabilities, add more messages or modify existing methods, and try these changes out on that same instance. The programmer could change the behavior of software describing an instance while the instance continued to exist.
6Although some programmers could argue that the per-message breakdown leads to these small method sizes (and undoubtedly it is an important factor), the claim about the impact of the screen space allotted by the browser is based on code comparisons that Steve Putz and I performed as part of a project to design a visual syntax for methods.
3.4.4.1. Smalltalk Supports Rapid Development
In 1977 Bob Taylor (then acting head of CSL) came up with an interesting idea for a PARC seminar. He proposed to invite the president and chairman of the Xerox Corporation, along with Xeroxs highest ranked officers, to spend two days at PARC. During that time, they would be presented with two important ideas: Computers of the future would be general-purpose devices customized by the addition of software to create business systems, and software would be created as a composition of otherwise independent components. As an example of the second idea, Taylor proposed that the researchers in CSL explain how their text editor (BRAVO) was both a standalone application and the text editor for an electronic mail system (a perfectly reasonable idea, if, in fact, it was not altogether available in the software in CSL at the time). Taylor further proposed that LRG create a hands-on laboratory in which the Xerox executives could experience the idea of component-based system creation, up close and personal.
LRG had nine weeks in which to design and implement a framework and a curriculum. The framework had to be customizable by various software components to produce different applications. The curriculum had to guarantee that each seminar participant would create a usable application. The framework created was a general one for specifying discrete, event-driven simulations, complete with a set of probability distributions for scheduling the arrival times and service times of customers and workers. The design was based on earlier work in SIMULA by Graham Birtwistle, called DEMOS (Birtwistle, 1979). The user interface consisted of an object browser that was a filter to display only four kinds of objects: Simulations, Stations, Workers, and Customers (rather than the entire Smalltalk library). By selecting one of the four classes of object, the user requested a list of all existing examples. Selecting Simulation displayed a list, such as CarWash, Ferry, ComputerNetwork, new. By selecting the item new, the user could specify another simulation, such as ProductionLine or CopierCenter. The user then selected one of the existing simulations and was shown the two important messages to simulations that had to be implemented (arrivalSchedule and availableResources). Similarly, selecting Station or Worker or Customer gave the user access only to those messages that had to be implemented in order to create a particular simulation. Built into the browser was some visual programming capability to draw images of simulation components and to specify the screen layout of stations. When the composed simulation was run, an animation appeared on the screen, along with a window in which statistics accumulated.
The simulation kit offers an interesting example of the kind of uses for which Smalltalk is best suited. Smalltalk systems contain a model of how types of components interact, here a model of event-driven simulations. There is also a set of components for specializing that model, a set of viewing and interacting components for constructing specializations, and a set of tools with which to create new components, modify the model, and design new views and ways to interact. The simulation framework is abstract in that it provides a set of interacting objects that describes a general class of application but does not describe a specific application until the components are attached to the framework at appropriate points of customization.
The seminar for the Xerox executives was successful, but not without some cost.7 Nine weeks was hardly sufficient time to invent and implement the simulation kit, design and document five different customizations (all based on actual Xerox business experience and chosen so that the seminar participants could see the possible variety), and train mentors so that every participants success was guaranteed. But the real story happened a week before show time. The design of the simulation kit assumed that the class/subclass approach to specialization was the right one. Creating a new worker meant creating a new subclass of class Worker. Running the simulation with this new worker meant creating instances as needed. The Smalltalk-76 approach to object reference and automatic reclamation continued to use OOZE. But OOZE was designed with assumptions about the relative numbers of classes, instances, and subclasses. One week before the seminar, OOZE had to be redesigned and reimplemented to account for an increased demand on managing subclasses rather than instances. It was like pulling a support beam out of a completed house and replacing it, while the house was still being used, and expecting no new cracks to show up. It worked.
7I had given birth to my second daughter just before the seminar preparation began. As project leader, I was given an Alto to use at home, but towards the end spent many late nights at PARC. Terry Winograd kindly walked the corridors with a crying two-month-old Rachel. On the day of the seminar, my babysitter became sick, so Rachel attended the seminar as well!
Previous | Table of Contents | Next |