Previous | Table of Contents | Next |
Actually, we formed ParcPlace Holders, a corporation with the mission of creating a business plan for a software company. This corporation negotiated with Xerox, and later with Xerox and a group of venture capitalists, to form a company called ParcPlace Systems. The final papers were completed March 18, 1988.14
14Within 24 hours of the formation of ParcPlace Systems, Apple filed its lawsuit against Microsoft and Hewlett-Packard, claiming violation of Apples graphical interface design. ParcPlaces formation was announced in the Wall Street Journal, reporting the general opinion that Apples claim was without merit because most of the key graphical user interface (GUI) elements appeared first in the Xerox Smalltalk system. The lawsuit was even more peculiar because, by the mid-1980s, most of the original Xerox Smalltalk team was employed at Apple.
Although the politics of how we reached this point might be interesting to the curious historian, it takes us far afield from our Smalltalk technology story. The commercialization story is interesting inasmuch as it sets the context for further language and language system invention. Suffice it to say that the first release by Xerox15 of a commercial Smalltalk-80 system, named Smalltalk 2.1, occurred in the fall of 1986. The key developers were David Leibs, Russ Pencin, Ron Carter, Stephen Pope, Peter Deutsch, and Glenn Krasner. This system, along with systems from two other Smalltalk vendors on personal computers and the team from Tektronix, was exhibited at the first ACM OOPSLA (Object-Oriented Programming Systems, Languages, and Applications) conference in Portland, Oregon.16
15The ParcPlace team functioned under the Xerox umbrella for 19 months while negotiating with the Xerox lawyers for the technology transfer, so legally customers bought these first products from Xerox.
16OOPSLA was formed by researchers and company personnel from the Smalltalk, CLOS, Actor, and Eiffel communities, with seed funding from the discretionary budget of the then ACM presidentme.
The ParcPlace Systems (PPS) mission was to create a Smalltalk development environment that enabled programmers to create applications that were portable across all standard workstations, without recompilation yet with host system integration. The market tag line was write once, run anywhere. PPS accomplished its mission first by inventing new implementation capabilitya new C-based virtual machine called HPS and a faster, dynamic (just-in-time) compiler (Deutsch & Schiffman, 1984). Second, PPS created an operating system framework that could be specialized for each supported vendor system (Sun, HP, Apollo, Macintosh, and DOS personal computers). Third, PPS invented a user interface framework with specializations that emulated each of the standard windowing systems. PPS also improved on the performance and capability of the memory manager with the introduction of generation scavenging schemes (Ungar & Jackson, 1988). The consequence of this technology meant that from its first year, PPS sold and supported 11 different products, representing the 11 different configurations of processors, operating systems, and windowing systems that were popular on the market in the late 1980s. At a time when development costs were very high and target machine populations very diverse, the PPS portability story was well positioned, opening doors to major financial institutions as well as semiconductor and telecommunication companies.
3.5.5.1. Extending the Use of Dynamic Binding for General Composition
The early ParcPlace commercial experience was an adventure in redesigning the virtual machine for portability, creating product-level documentation to update and complement the books, and building up a quality training and consulting organization. Certainly the portability capability was without precedent. HPS represented an advance in Smalltalk implementation technology with Deutschs new code generation scheme that simultaneously achieved relatively easy machine portability, fast code generation, and good code quality. For business reasons, the scheme was not published. The object memory management in the virtual machine was significantly improved with a generation scavenger and weak finalization techniques that netted PPS its first patent. Deutsch worked on a new graphics model, investigating a model with full PostScript graphics contexts, coordinate transformations, and color space matching. Ultimately, Deutsch chose a graphics model for Smalltalk-80 that provided mappings for color capabilities and revealed pixel depth, color capabilities, and screen resolution to the programmer but was not fully resolution-dependent graphics like PostScript.17
17Deutschs opinion at the time was that the best graphics model for Smalltalk was one that would automatically convert colors to gray shades or halftones (later he added scaling for fonts), but that revealed pixel depth, color capabilities, and screen resolution to the programmer if desired. He strongly opposed integration with native user interface toolkits on the grounds that it would untowardly increase the maintenance burden from the platform fan out (that is, the need for different implementations for distinct operating system/user interface combinations). He advocated emulating the platform in Smalltalk using a framework approach, and then later endorsed using a framework whose concrete subclasses would link to the platforms toolkit. Allowing programs to invoke platform toolkit capabilities directly, he correctly predicted, would result in destruction of real portability.
Probably the most important contribution from PPS was the design architecture for the graphical application builder, known as VisualWorks. As early as 1988, David Leibs and I worked with the CIA to review and reconsider the requirements for the Analyst Workstation. We proposed a new concept for providing end user customization of knowledge management in the CIA, code named Sleeper. Buried in this work were the seed ideas for new ways to manage dependencies among system components and new ways to compose the viewing and controlling components of a GUI. When Kenneth Rubin, then manager of PPS training, convinced Leibs that his group needed a consultants GUI toolkit, Leibs returned to the original Sleeper ideas. He then worked with Frank Zdybel to create the VisualWorks application model and GUI layout framework.
The key idea was to take dynamic binding one step further than runtime method lookup by creating value models. A value model stores and retrieves a value using the messages value: and value. Any object in the system can become a dependent of a value model (consistent with the original MVC dependency and change broadcast mechanisms). Whenever it receives the message value:, a value model automatically broadcasts that a change has occurred to all objects that have registered interest. Additional protocol allowed an object to declare that its interest in the value model change should be served by sending itself or another object a particular message. Different kinds of value models provide various forms of communications about how system change should be channeled. The VisualWorks architecture is thus built on indirection and declarations of intentions (and therefore more in the design direction of Alan Kays original ideas that programming should be done as an expression of goals and strategies for meeting those goals).
Other Smalltalk vendors created GUI builders as well, hoping to create visual programming mechanisms that would accommodate a larger consumer marketplace for their Smalltalk products. Parts Workbench from Digitalk represented an attempt to reflect similar work at Microsoft for Visual Basic. Like its IBM counterpart Visual Age, Visual Basic offers a direct manipulation-style interface by which the programmer can literally show the system which objects to use and how they can communicate. These systems suffer from the inability to scale. The programmer shows the system how objects relate by connecting the objects with labeled lines. The usual confusions arise when textual programming must be mixed with line drawing and the lines (often called wires) must be displayed on the screen for the direct manipulation. Inevitably, complex systems look like colored spaghetti (Burnett et al., 1995).
Previous | Table of Contents | Next |