Stuff For Sale
2004 Summer Tour
In The Press
Veggie Van Gogh
Please patronize sponsors of this page!
Bytesmiths no longer is involved in software consulting. Maintenance of this web site is currently subsidised by unrelated business activities. Please pass the word to other interested folks, so I can continue to host this page!
- 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
- Dharm Atma Yoga -- Kundalini yoga instruction
- 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.
- Green Chipper -- light forestry and environmental services.
- Info Ark -- a huge collection of useful information.
- Varalaya Farm -- organic produce and sustainable farming education.
- 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
Your site could be listed here, for as little as $12 per month! Go to Bytesmiths Press for details.
This site has been selected by PC Webopaedia as one of the best on this topic!
This site has been awarded a Links2Go Key Resource Award in the Smalltalk category!
Originally published in The Smalltalk Report, November
Shoot-Out at the Mac Corral
by Jan Steinman
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
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.
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.
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
- objects receive events such as finalization prior to garbage
- 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
- 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
- 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
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.
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
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
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.
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: " 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: ". "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.
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.
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
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"
Related product reviews: go to the
next column in the series,
which describes Digitalk's Smalltalk/V-Mac, or go to a previous
product review we did on