This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Building Up vs Stripping Down
Feed Title: Richard Demers Blog
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rademers-rss.xml
Feed Description: Richard Demers on Smalltalk
The vwnc mailing list has been discussing what it would take to reverse the traditional Smalltalk development approach. Normally, one starts with a shipped Smalltalk image (e.g., that of VisualWorks) to which is added a variety of parcels for tools, database, graphics, communications, or whatever is needed by the new application. Programmers create or modify classes unique to the application; and then, everything that is not specifically needed by the application is stripped out to produce the releasable application.
The only problem is that "stripping the image" can be difficult and error prone, especially over a series of application releases. Because of complex dependencies, it can be hard to determine which classes are needed and which are removable. And even among the required classes, there are often many methods that are never used by the application. While some of this can be automated, it still remains difficult to hit the "minimum set" of required classes and methods. Many developers, in fact, don't bother stripping the image at all, or only strip out development tools.
In the vwnc mailing list, Terry Raymond asked, "what a stripped image for scripting would look like." He then proposed a list of Smalltalk capabilities (not specific packages or classes)and asked for comments. After a number of opinions were expressed, Travis Griggs commented, "I'd rather see a minimal image. Which can load parcels. Period."
So what would be in such a "minimal image?" It would be easy to start out by making a list, but one would soon run into the issue of what criteria to use in deciding what is necessary and what is not, which really depends on what one wants it to do. Instead, let me suggest an approach based on the Pacific system architecture of the IBM System/38, AS/400 and iSeries computers.
I've blogged about Pacific architecture before, in An Object-based Systems Architecture and in 18 Billion Billion, but there is another aspect that applies to this topic; namely, its layered design. Now layering is a commonly understood architectural pattern, but the Pacific architecture applied it vigorously, defining the following layers (from the bottom up):
Hardware
Wide-word microcode
Virtual machine (VM)
Operating System (OS)
Applications
In the System/38, layers 1 and 2 produced a rich CISC system that supported the requirements of layer 3, the VM layer. In later implementations of Pacific, layers 1 and 2 were replaced by RISC hardware and the VM layer was rewritten in C. However, the Virtual Machine Interface (VMI) between the VM and OS remained the same (though enhanced for additional requirements). OS and application programs did not have to be recompiled.
OK, now let's take this back to the discussion of Smalltalk images. Pacific architecture defined a Virtual Machine, and so does VisualWorks Smalltalk (as did the blue-book description of Smalltalk-80). But these VM's are actually at different levels of capability. Smalltalk's VM is an abstraction of the commonly found computational, branching and control instructions of machine-level architectures. Smalltalk systems then rely on extensive libraries of compiled classes for everything else, including memory and process management. In contrast, Pacific's VM includes generic instructions for computation, branching and control, but goes much further by also supporting memory and process management, tightly integrated security and concurrency, and support for database and communications management.
I am not going to advocate moving all kinds of system support into the Smalltalk VM, but I think it would be useful to look at the Pacific VM as a model for a layered Smalltalk image.
And I am not going to advocate a rigidly enforced interface barrier in the middle of the Smalltalk image.
Instead, think of the computational and system management functionality needed by most applications. That goes below the new Smalltalk Machine Interface (SMI) and is part of every Smalltalk image; everything else goes in separate parcels (whatever they are called), and can be loaded dynamically.
A secondary, though perhaps equally important, result of defining such a Smalltalk Machine Interface is that it could become the basis for something else sorely needed by the Smalltalk community, an industry standard.
Previous Topic
