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, January 1994.
Shoot Out at the Mac Corral, Part 2
by Jan Steinman and Barbara Yates
27 November 1995, the authors
The latest (but pre-merger) word we had on this product is that no
new development is planned for it. We can only speculate that the
PPS-Digitalk merger has made it even less likely that this product is
a viable option for Mac Smalltalkers.
About ten years ago, a Smalltalk product called Methods was
introduced for IBM PCs and clones. This product grew into the
Smalltalk/V product family that now largely dominates the IBM
compatible Smalltalk market.
Along the way, a specific need for a Macintosh product arose, and
the first Smalltalk/V Mac was shipped in November 1988, built largely
from acquired technology.
As corporate MIS departments discovered Smalltalk, and IBM itself
endorsed it, more and more effort went into enhancing and refining
Digitalk's IBM compatible line, while the Mac version went through
only two minor "bugfix" update cycles, culminating in June 1991 with
version 1.2, which sold for $199.95.
In 1992, Digitalk acquired Instantiations, a Smalltalk consulting
company largely derived from the remains of the disbanded Tektronix
Smalltalk product group. This Portland, Oregon based group brought
extensive knowledge of both 680x0 Smalltalk virtual machine
implementation and Smaltalk 80 virtual image internals.
It is not surprising that this flow of history should result in
August 1993 with the first major upgrade of Smalltalk/V Mac since its
introduction. Version 2.0, while overdue, is impressive: about three
times the number of classes and methods are in 2.0 as were in 1.2.
Although the price has increased by a similar factor to $495, it is
probably still the least expensive commercial Smalltalk available
today, and even more so if it is still available at the upgrade price
af $195 in effect at the time this was written.
Part 1 of this series (in
the November 1993 issue of The Smalltalk Report )
described a new and original Smalltalk implementation,
SmalltalkAgents, from Quasar Knowledge Systems. (A brief update on
their progress appears in this article.) Also available for the Mac
is Visualworks\Smalltalk 80 from ParcPlaceSystems.
(For convenience, the three dialects will be referred to as STA,
ST 80, and ST/V, respectively. Unless otherwise noted, use of "ST/V"
refers only to the Mac 2.0 version, not the other products in the
Highlights and Changes
Unfortunately, we must begin the feature list with an omission.
There are no release notes or concise description of the differences
between version 1.2 and 2.0. Those already familiar with ST/V will
quickly spot major additions, but many small improvements -- and
incompatibilities with version 1.2 -- await to be discovered. This
makes it difficult to plan a port; it would be nice to know concisely
what had changed, so that one could scope the porting effort.
Among a long list of long awaited features claimed by Digitalk for
version 2.0 are: DAL/DAM SQL, 32 bit color QuickDrav, QuickTime,
Balloon Help, and AppleEvents. We'll look at just a few new things in
There is a new specialized Inspector for windows available on the
Window menu. This is a useful tool that many people end up building
themselves -- we'd like to see in all dialects of Smalltalk. It
eliminates the need to open many levels of Inspector to figure out
what is going on in the application window you are developing.
Figure 1: a Class Hierarchy Browser and Window Inspector.
Class Hierarchy Browser
The Class Hierarchy Browser has a different arrangement of panes
and buttons, but otherwise it appears to be similar to that in 1.2.
One pane lists the local and inherited instance and class variables
of the class. Selecting in this pane filters the methods list to
accessors and setters of the variable. Clicking again on a list
selection does not deselect it, so it is not obvious how to unfilter
the methods list.
Find Class in the Classes pane now works with
wildcards, but it is fussy. When searching for window classes, all of
these tries (*wind*, *windo*, *window*, *window, and *Window) were
rejected with the same message: "Please enter a more specific
pattern." This was frustrating, and not very useful!
The access to the senders or implementors of a message in a
selected method requires more menu actions in 2.0 than in 1.2. We
found the extra steps annoying, and we disliked having to have an
extra window open to get to the information we wanted. Developers
with small screens will especially notice this difference, although
ST/V is still more screen efficient than STA.
Text automatically word wraps in code panes. This feature is
replaced by horizontal scroll bars for any window in which the user
turns auto wrapping off. ST/V's non word wrapped heritage is
irritatingly apparent -- method comments are formatted wider than the
default window width, which makes for difficult reading.
Temporary variables are automatically generated for code written
and executed in workspaces. (This is obviously part of the new
Tektronix heritage -- wherever two or more former Tek Smalltalkers
gather, they bemoan the lack of workspace variables!) Another
improvement is that workspaces saved to a file and later reopened
retain their text fonts and emphasis. Unfortunately, along with the
improvements comes a large increase in the amount of time it takes to
open a workspace from a file over that required in 1.2. This exceeds
a 10:1 performance decrease in certain situations we encoundered.
Events -- A Roadmap
The classic Smalltalk "dependents changed/update" mechanism of
user interaction is showing its age, and Smalltalk developers are
clamoring for event driven operation. ST/V Mac 2.0 uses a strategy
for change initiation and propagation that may be simpler to program
than the classic dependency mechanism.
The advantage of true event handling is that polling of user
interface components is hidden, ideally by direct use of operating
system services. Rather than polling the state of input devices and
locations in Smalltalk code, user actions and other system happenings
spontaneously result in the evaluation of Smalltalk expressions.
Apparently, this is not quite the way ST/V operates -- it still
has a single bottleneck Smalltalk Process that gathers and dispatches
operating system events, so the differences tend to be syntactic
rather than semantic.
Perhaps the worst way to try to attempt to understand the ST/V
event dispatching is the way we initially tried. Merely browsing the
code of Application and related classes does not quickly reveal how
to use ST/V event dispatching effectively. This is the approach of
those who are unused to having in depth documentation!
Those who are used to "changed/update" event dispatching may want
to start with Tutorial Chapter 9, Windows, even if they normally do
not "do" tutorials. Tutorial Chapter 10 also looks at building your
application window and setting up events. Next, an examination of
Application class in the Encyclopedia of Classes, combined with a
reading of the Programming Reference chapters 6 (Building a User
Interface) and 7 (Extending the User Interface Framework), will
rapidly add to your understanding of setting up, triggering, and
responding to events.
At this point, browsing the code of existing Application
subclasses is fruitful. Eventually, the serious Smalltalker will want
to memorize Appendix C, or at least make up a "cheat sheet" from it.
To maintain one paradigm between user initiated object change and
other abject changes, ST/V "events" replace the generic
update sent to all dependents of the object
receiving changed . This somehow feels less object
oriented -- previously, an object's dependents decided at run time if
they were interested in that object's happenings, now the object must
register for specific happenings, thus weakening the traditional
model/UI division of responsibilities. ST/V makes this difference a
bit less onerous for pre 2.0 applications by configuring an event and
action when an application receives the
addDependent: message, therefore providing some
compatibility for many cases.
Are events, as implemented in ST/V, "A Good Thing?" They are
undoubtedly valuable for capturing user actions, yet they can
certainly be abused. We can't say that the result is easier to
understand, debug, or maintain than the classic "changed/update"
mechanism, and it may prove less flexible in complicated situations,
but it is probably simpler to program in most situations.
Either way, the developer porting to 2.0 will not be able to
ignore events, since they are firmly embedded in the application
architecture. Perhaps some third party user interface builder will
come to the rescue, providing more support for putting events in
There are three manuals: Tutorial, Programming Reference, and
Encyclopedia of Classes, comprising about 2 1/2 times more material
tan found in the 1.2 manual. We found the Encycopedia's methods index
useful as a reference for standardizing selector names. The reference
book is well written, and its Appendix C on Events is a valuable
condensation of events information. Another nice section, especially
for the beginner, is The Glossary, which defines most of the terms
used throughout the documentation.
Finally (and perhaps most importantly), all of the methods we
looked at had comments. A method on the class side called
COMMENT is used to provide class comments. Although
using a special method for class commentary is somewhat of a hack,
the fact that there is commentary is an area in which
ST/V beats both STA and more recent additions to ST 80.
One reason some choose ST 80 is its flexible exception handling
mechanism, since ST/V had none. Digitalk now has something similar to
the PPS context unwind/marked method exception mechanism, but they
made it somewhat easier to use, at the expense of being somewhat more
difficult to create special cases. For example, both exception
systems have a special purpose "do this thing, and then whatever
happens, make sure to do this other thing" mechanism, since that is a
useful way of releasing external resources, such as files. In ST 80,
the mechanism involved "leaks through" into the method selector; you
need to use the rather unwieldy method:
[statement with possible error] valueNowOrOnUnwindDo:
[statement that always executes]
ST/V uses the simpler, more intuitive:
[statement with possible error] ensure:
[statement that always executes]
Likewise, a block that is only executed when some other statement
has a problem is invoked using valueOnUnwindDo: in
ST 80, and ifCurtailed: in ST/V.
Like ST 80, ST/V also has a more general exception mechanism,
using a block centered, class based approach, rather than the Signal
centered, instance based approach pioneered in ST 80. For example, in
handle: [:exception | exception return: 0]
returns zero if y is zero, whereas in ST/V:
do: [:exception | exception exit: 0]
does the same thing, using analagous components. ST/V is simpler
to use in simple cases, but requires more work to set up new
exceptions, since they must be coded as complete classes. In ST 80,
new exceptions are very simply coded in the class protocol of objects
that will be generating them, but are therefore not global, making
the user of them work a bit more to protect a block of code.
A completely different approach is used in STA, which requires
exceptions to be coded as compiler directives. This may be the
easiest of all to use, but the STA exception mechanism was
undocumented at the time of this review; this opinion is based on
browsing examples in the STA image.
Digitalk provides well regarded suport through their CompuServe
forum. They announce all patches and bugfixes, and allow downloading
to registered licensees. This again shows Digitalk's strong PC/clone
bias -- a Mac user is more likely to be on America Online, AppleLink,
or Usenet than CompuServe. We've seen grumblings in the Usenet
Smalltalk newsgroup about CompuServe users getting more attention
than Internet users.
For example, until we asked about the availability of patches, we
had no way to know they existed. We were fortunate to have personal
contacts among the team responsible for ST/V (special thanks to Pat
Caudill, the ST/V Mac project leader), so we got good response when
we inquired about bugfixes. However, we can't write from firsthand
experience about general responsiveness of technical support for
ordinary customers. We also do not know how the typical customer
finds out about the availability of bugfixes, other than via
CompuServe -- we have been licensed for ST/V Mac since 1990, and were
only notified of major upgrades available for an additional fee.
After installation, we carefully write protected the image, so
that we would not inadvertently change something that would affect a
measurement. We then experienced repeated application crashes upon
launching. This was extremely frustrating, until we discovered that
you cannot run a write protected image.
In ST/V version 1.2, a notifier tells you this and lets you exit;
in 2.0, it simply crashes into Macsbug. ST 80 happily runs a write
protected image, allowing you to save to an alternative file name
upon save; STA cryptically opens a standard file dialog, and when you
choose the write protected image, it gracefully exits, without ever
telling you why. We much prefer the ST 80 tactic, and wish other
vendors would adopt it.
Other than the write protect incident, we experienced only one
unexplained application crash. On attempting to resize a window on a
28k file, ST/V died with error #25 (dsMemFullErr, out of memory). On
the other hand, we experienced numerous walk backs (with version 2.0)
when trying things as reasonable as installing Digitalk supplied
At the time this was written, there were two files of bugfixes and
a new application and image, together known as version 2.0.2,
available from Digitalk. Together they correct over 70 bugs, with
about 25% of them classified as serious problems (walkbacks, methods
silently misperformed, crashed application).
However, we could not get the patch installer to work by following
the supplied README file. Bypassing the installer and manually filing
in the patch files worked somewhat, but we also had to update the
image's idea of which patches were installed, so that other files
(such as the newly patched Compatibility.st) would file in. It took
over an hour to install the patches, which seems unreasonable --
upgraders should get the new image and application, and not bother
with the patches.
Later, we looked more closely at the installer problem. "Directory
current," used by the installer, answered the top level directory,
not the actual directory from which ST/V started. We moved our
directory to the top level folder and the patch installer worked.
Incidentally, one of the patches corrected this problem -- Digitalk's
QA department must be using their prescient version of the patch
Fortunately, version 2.0.2 is much more stable, and all the
problems we recorded in 2.0 (except for the write protect crashes)
appear to be solved.
Unlike STA, ST/V is not copy protected, and it can be moved
between machines as allowed under US copyright "fair use" doctrine.
(Our review copy did not come with a license, so we cannot say that
this would fall within a strict reading of the Digitalk license, but
at least it is possible.)
However, like STA (and other ST/V dialects), certain classes (such
as the compiler) are protected, and they cannot be viewed, modified,
or debugged. This is lamentable -- changing the compiler isn't
something one should do every day, but having the option to do so may
make some problems simpler. Those who are attracted by Smalltalk's
reputation as an open system have ST 80 as their only alternative at
Porting from 1.2 to 2.0
Digitalk describes 2.0 as "a top to bottom re write of Smalltalk/V
for Macintosh," and like all things in life, this is both good news
and bad news. We've tried to give an impression of the depth and
breadth of the good news.
The news is not entirely happy for users who have to port their
applications from 1.2 to 2.0. The lack of release notes means that
the user has no first line of approach to discovering puzzles like
removed or changed classes. (In comparison, Object Technology
International lists each changed method in their release notes,
greatly easing the porting task.)
Several developers we surveyed said the port of their 1.2 code was
not simple. "I thought I knew ST/V Mac really well," said a developer
who had been with ST/V Mac for three years, "but now I'm having to re
learn a lot." The many new features are strongly desired in the
developer community, but many were bewildered by the magnitude of the
changes. A "Porting Guide" section in Digitalk's othewise fine
documentation would go a long way to redress the lack of release
Also, 1.2 contained a popular "goodie" called Application Browser
that aided users in creating file out packages to rebuild their
application in another image. Not only is this goodie missing in 2.0,
but the global name Application is taken for an entirely
different purpose, so all files made with the 1.2 Application Browser
require editing before installing them in 2.0. Digitalk is
experiencing customer pressure, and will probably replace the
Application Browser in some form.
The following table, which originated in last month's STA article,
compares available Macintosh Smalltalk implementations. Readers
should refer to that article for additional information on how we got
our numbers. Changes since that article are underlined
[951127-JWS: in parentheses in HTML port].
Since last month's article, we've added two measurements. In an
attempt to include some idea of high level performance, we added a
simple timing of how long it takes to open a window on a 28k styled
text file. (Only STA and ST/V 2.0 displayed the text appropriately
styled.) While this is not a particularly rigorous test, it tends to
parallel the slopstone and smopstone benchmarks against STA and ST/V
1.2, although it counters to some extent the results against ST 80,
which has sluggish linear read file performance, due to multiple
We also added a line for the application (vs image only) disk file
As we mentioned last month, low level benchmarks do not
necessarily predict the performance you'll get. To paraphrase Mark
Twain, there are "lies, damn lies, and benchmarks!" In particular,
ST/V (and STA) is much closer to the Mac than is ST 80, so windows
open faster and menus drop quicker than they do in ST 80's Mac
Most of the measurements of 2.0.2 are within 6% of those of 2.0.
There are 503 new methods, which add 118k to the image size. This
seems like quite a bit for two minor rev cycles, and indicates the
youthfulness of the product.
The number of classes can be misleading, and does not necessarily
correlate with quantity of functionality. Recall that ST/V has a
class per exception type, while ST 80 has a method per exception
type. Also, 181 classes -- nearly a third of the total -- have names
that begin with "Mac", indicating functionality may be distributed
among more classes in ST/V than in other Smalltalk dialects.
The first column for each implementation (the percent numbers)
lists that implementation's measurement 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.1b15) ST/V 1.2 (ST/V 2.0.2) ENVY/VisualWorks
start up time  (33%) (16) 15% 7.3 (81%) (39) 100% 48
image save time  (94%) (16) (19%) 3.3 (100%) 17 (94%) 16
slopstone (no FPU)  100% (0.14) (38%) 0.054 (32%) (0.045) (26%) 0.037
slopstone (FPU)  (87%) (0.20) 30% 0.070 (26%) (0.059) 100% 0.23
smopstone (no FPU)  100% (0.19) (24%) 0.046 (18%) (0.036) (21%) 0.039
smopstone (FPU)  (100%) (0.27) (22%) 0.060 (20%) (0.053) (81%) 0.22
28k file window  (35%) (1.8) (35%) (1.8) (84%) (4.3) (100%) (5.1)
required memory (k) 85% 3500 35% 1465 65% 2654 100% 4096
preferred memory (k) (50%) (5000) 20% 1953 36% 3584 100% 10003
image size (k) (56%) (2316) 16% 669 (53%) (2191) 100% 4121
application size (k) (96%) (492) (17%) (88) (43%) (222) (100%) (512)
number of classes  (42%) (340) 20% 165 (75%) (606) 100% 811
number of methods  (39%) (6685) 20% 3490 (62%) (10693) 100% 17268
- time in seconds, measured with a hand held stop watch, using a
fast 11 mS disk.
- Mac PowerBook Duo 210: 25 MHz 68030, 12 MB RAM, 80 MB disk, 1
bit LCD, System 7.1, no system extensions or power saving.
- Mac IIci: 25 MHz 68030, 20 MB RAM, 32 kB cache, 80 MB and 1.2
GB disks, 1 bit internal video, System 7.1, no system extensions.
- poor result possibly due to memory starvation -- could not
obtain "preferred" memory, and had to settle for a mere 9560k.
This result was disturbing, so we repeated it -- and gave up after
- strongly correlated with file size -- ST 80 was actually as
fast as ST/V 1.2 for very small files.
- STA uses one file, image size is data fork size, application
size is resource fork size.
- includes ENVY, which adds 126 classes and 3213 methods.
- fewer classes than previous version -- a number of demo
classes appear to be "unbundled" in files, rather than be
delivered in the image, although the method count is actually
higher in this version.
- obtained via "MetaClass allInstances size", which may include
classes with hidden source code.
- obtained via "CompiledMethod allInstances size", which may
include methods with hidden source code.
Figure 2: "should I use it?" decision tree.
At article deadline time, we had just received STA version 1.1b15.
Although nomenclated as a beta version, QKS assured us that short of
crucial bugfixes, what we received is identical to what is shipping
by late November as version 1.1. We've updated the measurements table
with data from the new version.
The new measurements show that QKS has not been on vacation these
two months. Essentially every measurement has improved in that time.
The smopstones doubled in performance, while the preferred memory
size was reduced 17% and the image plus application size went down
5%. Keep in mind that the removal of internal debugging code probably
accounts for much of the size reduction, and possibly some of the
speed improvement as well.
More important than the measurements is that STA 1.1b15 feels much
more stable than the version 1.0.1 previously reviewed. We
experienced no application crashes or debuggers while evaluating
Only speed and quality appear to have changed since we last
described STA. The biggest omissions of version 1.0.1 still exist: no
manual, no GUI builder, no crash recovery strategy, partially
implemented inspector and debugger, non standard command key map,
etc. STA remains a product with exciting potential, suitable for
early adopters and pilot projects, but don't bet your business on it
Digitalk's Smalltalk/V Mac version 2.0 is an ambitious upgrade to
version 1.2, and is a bargain, even at the full list price. Those
with ongoing ST/V Mac projects should not hesitate to port to it,
although such a port may not be trivial. Three times the quantity of
code and eased access to the toolbox alone make it worth switching
for ongoing development, and the addition of exception handling alone
may be enough to justify a port of ongoing work.
However, three times the code potentially means three times the
resource consumption. Those with completed ST/V applications may not
want to port to 2.0 if RAM usage, disk size, and performance are
utmost issues. Those who are supporting an existing application that
must work nicely on an old Plus or Classic might consider staying
Those considering new development need to ask a number of
questions before settling on ST/V. Are you willing to watch
CompuServe for the inevitable patches and bugfixes that come with a
young product? Do you need the utmost performance? Are you already
comfortable with another vendor's product? Will you be working with a
team? Do you need to work on multiple platforms? None of these
questions alone may rule out ST/V, but if many of them are issues, a
different vendor's Smalltalk may be appropriate for you.
Related product reviews: go to the
previous column in the series,
which describes Quasar Knowledge Systems SmalltalkAgents, or go to a
previous product review we did on