• Bytesmiths Editions -- large, archival, fine-art photography on unusual materials
• Bytesmiths Press -- artists' services: web design/hosting, jury slides, giclee reproductions, opening announcements, brochures, etc.
• Champagne Beadworks -- handcrafted jewelry and beadwork
• Crafted By Carol -- handcrafted jewelry and beadwork
• EcoReality, an organization devoted to establishing a sustainable ecovillage
• Ecovillage Newsletter -- Diana Leafe Christian's news of her travels.
• Environmental Education Outreach -- providing environmental education worldwide.
• Gemini Gypsy -- Carole Good-Hanson's fused glass frames
• Green Chipper -- light forestry and environmental services.
• Salt Spring Island Society for Community Education -- community education on our island of 10,000.
• Veggie Van Gogh -- two artists' mobile warehouse and living quarters, petroleum-free!
• Veggiemog -- life and times of Kelly O'Toole's Unimog, running on biodiesel

Preface

27 November 1995, Jan Steinman

This article describes a beta version of Smalltalk Agents. The product has been in continuous development since publication, and many of the concerns we expressed in this article have been addressed.

Shoot-Out at the Mac Corral

by Jan Steinman

One of life's little ironies may be drawing to a close. It is argued that Smalltalk's greatest mark on the world has been via its direct influence on Apple and the highly successful Macintosh line of computers. This Mac-Smalltalk connection has forever changed even the greater world of computing, due to its subsequent influence on X-Windows and Microsoft Windows.

Yet the Macintosh has never really had a credible Smalltalk implementation. An implementation of Smalltalk-80v1 was developed at Apple in the early Mac days, but its performance was inadequate for anything except OO research. Digitalk produced a useful Mac implementation, but let it languish while they lavished resources on their popular MS-DOS products. In keeping with an otherwise admirable policy of "portability at all costs," ParcPlace's Mac implementations had difficult access to native platform features and were perceived as painfully slow on all but the top-end Macs.

Thus the machine that owed the most to Smalltalk paid it back the least. Mac fans who were also Smalltalk fans suffered the benign neglect of a second-string product; Smalltalk fans who were also Mac fans worked on Suns and PC-compatibles by day and went home to their Smalltalkless Macs at night.

This situation is about to change with a brand-new, original Mac implementation of Smalltalk, and a major update to a venerable existing product. This article explores an exciting (though vexing) newcomer to the Smalltalk world, SmalltalkAgents, from Quasar Knowledge Systems. In a future article, we'll take a look at Digitalk's Smalltalk/V for Macintosh, version 2.0.

Enter SmalltalkAgents

Now Mac fans have an alternative to the ParcPlace and Digitalk offerings in SmalltalkAgents, from Quasar Knowledge Systems. It follows the Digitalk tradition of making a clean break with its Smalltalk-80 heritage -- the class hierarchy and user interface are much more different from Smalltalk-80 and Smalltalk/V then they are from each other. (For convenience, we'll refer to the three dialects as ST-80, ST/V, and STA.)

Figure 1: some SmalltalkAgents screens.

STA departs from traditional Smalltalk in many ways, most of which are good ideas. For instance, the global name space has been segmented, so that class names can be repeated in different contexts, or libraries . There are a few not-so-good ideas, however, such as a sprinkling of C semantics that leaks through, ostensibly for performance reasons. For now, at least, I'll list all such differences as features , and will discuss the implications of some of these later.

Features

Following is a quick list of features claimed by STA. At the time this article was written, QKS was shipping version 1.0.1 at a discount; it was missing some features slated for the "final" release, including a useful manual. The features not available at press time are noted below. Some of these features may be available in the currently shipping product as you read this.

• tight, seamless integration with the Macintosh OS; direct access to most Macintosh services, including XCMDs and XFCNs, Quickdraw, access to Mac resources, machine and OS interrupt handling, and class-level interfaces to advanced Mac concepts, such as tear-off menus.
• scoped, nestable public name space, rather than global namespace -- "Smalltalk" (instance of SystemDictionary ) is replaced with multiple instances of Library . The "Environment" library has global scope; the others are accessed via their containment relationship to Environment . Any class can declare any library as a pool, thereby accessing that library's name space. One class can appear in multiple libraries, under different names, which can be useful for class name aliases, and portability between Smalltalks with different class names.
• a unified object model, without concern for the differences between named or indexed storage, or the size of storage elements. Object state can be named or indexed, and is dynamically sized. All indexable objects understand streaming protocol.
• any object can contain "structured storage," which is a block of memory that is interpreted independently of the object, for example, a Mac resource or a C struct. Accessing such storage is direct; it does not carry the overhead of copying.
• all objects are capable of functioning as Strings. Strings hold 8, 16, or 24 bit elements in any combination.
• objects have property lists, which indicate such things as whether the objects is immutable, or if it is fully resident in memory. (All objects have the basic capability to be known by proxy.)
• objects receive events such as finalization prior to garbage collection.
• source code is stored as styled text, and names may contain 16 or 24 bit characters. Syntax is added for literal styled text.
• blocks can take variable number of arguments, and be reflexive via the pseudo-variable blockSelf . Syntax is added to explicitly declare local or global scoping of block arguments, which allows much better performance if block locals can be used. This is also an improvement over ParcPlace's "clean/copying/full" hidden block semantics, since only sophisticated developers fully understand how to write a block for maximum perfyormance.
• class Switch supports case statements.
• local variables are automatically declared -- they need not be declared at the top of the method, as in other Smalltalks.
• call-by-reference is supported: formal parameters can be modified, and the modification is reflected in the actual parameter in the sending context.
• C-style syntax for Integer bit operations; C-semantics for true and false. All objects are equal to true, except 0, nil, and false, which are all equal to each other.
• arbitrary-precision primitives. This could be extremely useful in financial software, since Float should not be used for counting money!
• syntax added to support compiler directives. This has potential for improving performance by providing "type hints" to the compiler.
• pre-emptive, time-sliced (UNIX-style) processes.
• general-purpose catch-throw exception handling mechanism, similar to the C setjmp/longjmp.
• an event-driven (as opposed to polled), non-MVC GUI frameworks.

Features Missing from Beta Version

The following features are referred to in the beta manual, but were not available at the time of review.

• GUI Builder. (Actually was partially present, but the source code was protected, and no documentation was provided.)
• inspectors were partially operational, without access to properties, structured storage, or self .
• the Binary object loader/unloader was not available, nor was there automatic source code management (limited to file-in, file-out, with no crash recovery).
• WorldScript/Unicode is incomplete.
• debugger was partially operational, with no access to self or modification of temporaries.
• compiler had debug/trace code installed, and lacked speed.
• DAL interface
• 32kB limit on text views.
• no network classes.

Problems

STA is a young product, and it shows in many ways. While application crashes were rare, they did occur. On the other hand, QKS technical service was especially responsive, both in my personal experience, and as related by others.

The STA virtual machine proved fairly stable for any software nomenclated "1.0.1". Only a few application crashes occurred during my use. However, there does not appear to be the equivalent of a "changes file," all source code is currently kept in the image. In this situation, one quickly learns to save often! On the list of promises is a source-code database of some kind, with multi-user facilities.

Short of outright crashes, a number of features had problems that might be expected in such a young product. For example, the messages in the debugger window were often wrong or misleading. I became used to routinely not trusting what it said, and opening a full debugger to see what was really happening. Even then, the debugger is but a shadow of what Smalltalkers have come to expect. You cannot evaluate expressions in the debugged context, nor can you change the method and re-start, return arbitrary expressions, or modify temporaries.

I was unable to send messages to "self" in either an inspector or debugger, which greatly reduced the usefulness of the debugging environment, since one often goes into an inspector to evaluate expressions, like "self halt problemMethod." On the promise list is a true breakpoint facility, which would be a welcome improvement over the typical Smalltalk habit of inserting halts in the source code.

In general, the development environment has rough edges. The browsers are impressively colorful, but lack the spatial efficiency that users of other Smalltalks take for granted. For example, over half the area of a typical inspector is taken up with a large "Properties" check-box area, which apparently displays static flag information that might be more efficiently displayed as a binary or hex number and legend. Code browsers devote nearly an inch of the view to iconic buttons. This is not a product that is comfortable to use within a 640 by 400 screen!

The euphemistically named "Beta Manual," which seemed to be galley proofs of several chapters combined with some design objectives, was nearly useless, especially to an experienced Smalltalker. Most of it was an overview of OO principles, and some of the example code did not even work. Hopefully, QKS is shipping a final manual by the time you are reading this.

Mac users are generally resigned to incompatibilities with various system extensions. I found that Now Software's WYSIWYG Menus 3.0.1 caused the format menu to be unusable, and that Adobe Type Reunion 1.1 disabled the font menu. No other system extensions proved troublesome. (Although I did not try STA with every system extension in the world, I normally have three rows of icons at boot-time!)

Compared to ST-80 (and even ST/V), there are few comments in the code. This is a terrible thing to do in a system that relies so heavily on source code access, and is especially troubling to those familiar with a different Smalltalk, since many methods are close enough to make you think you know them, but they operate differently. The lack of a manual would be little trouble to experienced Smalltalkers if the source were better commented.

STA handles modified keystrokes in a non-conventional way, following the currently installed keyboard resource (KCHR) for only shift, caps lock, and option modifiers. This is annoying and frustrating for Dvorak typists and those who re-map their function keys to their liking. QKS argues that there is no standard for other modifiers, but if Claris and Microsoft can agree that command plus whatever key is defined as "Q" always quits an application, then QKS should also! If you use a macro program such as QuicKeys, be prepared to lose your custom function key mappings while running STA.

Following Digitalk's lead, QKS has protected some of its source code. Just when things start to get interesting in a debugger, you are confronted with "** QKS has removed the source **" This is a regrettable, but growing trend in Smalltalk -- some may choose to stick with ParcPlace simply for their complete source code access, especially to the compiler classes. Given the lack of a credible manual, the lack of any source, commented or not, is inexcusable. QKS has several years headstart on any new competitor (and ParcPlace and Digitalk aren't paying attention to QKS yet), so source code protection is no more forgivable than copy protection.

Speaking of which, a real nuisance is the serial-number-entry style of copy protection QKS has implemented. Moving an image causes it to assume that it has just been installed, and it requests a 13 character key before doing anything useful. People who need to test their work on different platforms will hate this. I had particular problems with this, since I was moving a single image between two machines for comparative benchmark measurements. QKS should follow the lead of all major software vendors, and exhibit some trust in the ethics of their customer base.

Compatability

This is a burning issue of such importance that it may make or break the future of any new Smalltalk implementation. QKS has made a number of controversial decisions that impact portability with existing Smalltalk dialects, decisions that change the very relationship between basic system classes.

Protocol has arbitrarily been changed from the de-facto Smalltalk standard. For example, in other Smalltalk dialects, the message "|" is only sent to a Boolean, and it answers the logical OR of the argument and the receiver. STA defines it as a numeric OR, which is called "bitOr:" in all other Smalltalks. This is much more severe a change than the spelling of metaclass, for example. (ParcPlace calls it "Metaclass," Digitalk calls it "MetaClass.")

This is simply wrong -- it doesn't matter so much if one wants to change the implementation of classes (as QKS has with collectives), but the very definition of an object is its behavior . Luckily in this case, it is not such a problem, since boolean operators that evaluate their argument are discouraged in favor of "short-circuit" boolean messages, such as "and:" and "or:."

But wait, we're not out of trouble yet. Quick, what is "347 and: [true]?" If you have been with Smalltalk for some time, you might answer that it doesn't make sense to send "and:" to "347," but in STA, this statement evaluates to "true." An interesting side-effect is that such boolean messages are no longer commutative: "347 and: [true]" answers "true," but "true and: [347]" answers "347." This is going to be a maintenance nightmare -- when someone changes the order of short-circuit boolean messages to improve performance, the behavior of entire systems may change.

(Perhaps one should not be so hard on QKS for this. Starting with VisualWorks, ParcPlace changed the semantics of "and:" -- along with all other messages that take a no-argument block -- simply by implementing "value" in Object to return self. The statement "true ifTrue: 347" evaluates to 347, but takes much longer to execute than "true ifTrue: [347]". "Hidden-time" is a ParcPlace weakness (as with different block semantics); it would be regrettable to see QKS follow in that path.)

QKS defends their boolean equivalence policy vigorously, citing C and Lisp (while conveniently ignoring Pascal, Modula-2, Ada, et. al.), and VM efficiency as reasons. They have taken considerable criticism from the Smalltalk community on this, and may yet yield to pressure to conform with established boolean semantics.

Other compatibility issues are more easily justified, and generally have work-arounds. For example, much of the collection and stream hierarchy is subsumed by class List , but with multiple libraries (any of which can be declared as a pool), it is simple to create aliases for List called Array , OrderedCollection , WriteStream , etc. QKS is promising eventual file-in compatibility for major base classes, but as of version 1.0.1, it is safer to assume that there simply is no compatibility -- even basic class creation methods, such as needed to "file in," are completely different and incompatible.

Feature Comparison

The following table lists some items for comparison among some Smalltalk implementations available for the Macintosh. All measurement figures are rouded to two significant figures, which is within the variation we observed between trials.

The Samuelson Benchmarks ("Smalltalk Benchmarking Revisited," The Smalltalk Report , V2N8, June 1993) were run on two different platforms, both as a consistency check, and to assess the contribution of a floating point processor. The "no FPU" tests were performed on a Mac PowerBook Duo 210, which has a 25MHz 68030 and 12MB RAM. All other measurements were made on a Mac IIci, which has a 25MHz 68030 with a floating point processor, 20MB RAM, and a 32kB cache card. All measurements were made under "maximum performance" conditions: no system extensions or other applications running, 1-bit video, and no power-saving in effect, using System 7.1.

With two exceptions, all measurements were performed using the "preferred memory" partition -- if an implementation did not "prefer" extra memory, I did not offer it. I felt that changing the memory partition for one or more implementations would be arbitrary, and difficult to do for all of them in a fair manner.

The exceptions are the two "no FPU" measurements for VisualWorks. The Duo's 12MB RAM was not enough to allow VisualWorks to run with its preferred memory partition -- the Finder indicates that those measurements were run in 9560k. Note the dramatic, 6:1 reduction in performance in these cases.

Due to portability problems, many of the individual benchmark tests had to be modified to run under STA. Two SmopstoneBenchmark tests, "primesUpTo:" and "streamTestsOn:" would not complete, and were removed from the suite. The smopstone numbers are the geometric mean of the remaining tests in the suite.

The only VisualWorks image I had available was ENVY/Developer R1.41a as delivered by Obeject Technology International. This difference should not greatly impact most measurements, except for the number of classes and methods. (A PPS-supplied VisualWorks image is 4694kB and has 685 classes and 14055 methods.)

The measured start-up time was for a pure image, as delivered from the vendor. The measured save time was for the image plus the benchmark code. All disk-related measurements were made from a Fujitsu 1.2 GB drive with 11mS average access time.

The first column for each implementation lists that implementation's needs relative to the greatest in the group. In general, lower is better, although items such as "number of classes" are better the higher the number.

                    STA 1.0.1   STV 1.2    ST/V 2.0  ENVY/VisualWorks	
start-up time        42% 20     15% 7.3    71% 34     100% 48	
image save time     100% 18     18% 3.3    94% 17      88% 16	
slopstone (no FPU)  100% 0.076  71% 0.054  60% 0.046   13% 0.037	
slopstone (FPU)      74% 0.17   30% 0.070  27% 0.061  100% 0.23	
smopstone (no FPU)  100% 0.10   46% 0.046  34% 0.034   39% 0.039	
smopstone (FPU)      59% 0.13   27% 0.060  22% 0.050  100% 0.22	
required memory      85% 3500   35% 1465   65% 2654   100% 4096	
preferred memory (k) 60% 6000   20% 1953   36% 3584   100% 10003	
image size (k)       71% 2944   16% 669    50% 2073   100% 4121	
number of classes    45% 369    20% 165    68% 553    100% 811	
number of methods    34% 5892   20% 3490   59% 10190  100% 17268

Figure 2: "should I use it?" decision tree.

Summary

The SmalltalkAgents "post-Beta, but pre-real-thing" that I reviewed is brimming with promise. It pushes the envelope -- ParcPlace and Digitalk are busy fighting over the Fortune 500 MIS Sun/PC marketplace, and have neglected innovation on the Mac.

STA's performance seems remarkable. Although it benchmarks somewhat slower than VisualWorks, it feels faster -- windows open quicker, menus pop up faster, etc. VisualWorks employs dynamic translation of Smalltalk bytecodes into cached native machine code, a technique that excels with small, repeated loops, which is what these benchmarks measure. The Samuelson Benchmarks have acknowledged shortcomings, foremost of which is the lack of "huge operation" measurements; such "Shopstones" could have vastly different results than those obtained with low or medium level measurements.

Both exciting and troubling are basic changes QKS has made to Smalltalk. The addition of structured storage has the promise of greater integration of Smalltalk with other languages and systems, and the unified object model with weak references holds the possibility of less obtrusive garbage collection, and simple persistent storage and remote object facilities.

Yet this review was a difficult task: I wanted to like STA; there is much to like about it, and I want it to succeed, but version 1.0.1 is simply not ready for use as a workhorse commercial development environment.

The realities of business sometimes dictate that products are marketed and delivered before they are ready -- unfortunately, this has become the norm in software, rather than the exception. Given that the largest name in software produced their first credible windowing system with a version of "3.0," I would encourage early-adoptors to purchase and become familiar with SmalltalkAgents in non-critical applications until the real "real thing" is available.