for the lazy:
Date: Fri, 27 Feb 87 21:39:24 EST
From: John Rose
To: sun-users, systems
Pros and Cons of Suns
Well, I’ve got a spare minute here, because my Sun’s editor window
evaporated in front of my eyes, taking with it a day’s worth of Emacs
So, the question naturally arises, what’s good and bad about Suns?
This is the fifth day I’ve used a Sun. Coincidentally, it’s also the fifth
time my Emacs has given up the ghost. So I think I’m getting a feel
for what’s good about Suns.
One neat thing about Suns is that they really boot fast. You ought to
see one boot, if you haven’t already. It’s inspiring to those of us
whose LispMs take all morning to boot.
Another nice thing about Suns is their simplicity. You know how a
LispM is always jumping into that awful, hairy debugger with the
confusing backtrace display, and expecting you to tell it how to pro-
ceed? Well, Suns ALWAYS know how to proceed. They dump a
core file and kill the offending process. What could be easier? If
there’s a window involved, it closes right up. (Did I feel a draft?)
This simplicity greatly decreases debugging time because you imme-
diately give up all hope of finding the problem, and just restart from
the beginning whatever complex task you were up to. In fact, at this
point, you can just boot. Go ahead, it’s fast!
One reason Suns boot fast is that they boot less. When a LispM loads
code into its memory, it loads a lot of debugging information too. For
example, each function records the names of its arguments and local
variables, the names of all macros expanded to produce its code, doc-
umentation strings, and sometimes an interpreted definition, just for
Oh, each function also remembers which file it was defined in. You
have no idea how useful this is: there’s an editor command called
“meta-point” that immediately transfers you to the source of any
function, without breaking your stride. ANY function, not just one of
a special predetermined set. Likewise, there’s a key that causes the
calling sequence of a function to be displayed instantly.
Logged into a Sun for the last few days, my Meta-Point reflex has
continued unabated, but it is completely frustrated. The program that
I am working on has about 80 files. If I want to edit the code of a
function Foo, I have to switch to a shell window and grep for named
Foo in various files. Then I have to type in the name of the appropri-
ate file. Then I have to correct my spelling error. Finally I have to
search inside the file. What used to take five seconds now takes a
minute or two. (But what’s an order of magnitude between friends?)
By this time, I really want to see the Sun at its best, so I’m tempted to
boot it a couple of times.
There’s a wonderful Unix command called “strip,” with which you
force programs to remove all their debugging information. Unix pro-
grams (such as the Sun window system) are stripped as a matter of
course, because all the debugging information takes up disk space
and slows down the booting process. This means you can’t use the
debugger on them. But that’s no loss; have you seen the Unix debug-
Did you know that all the standard Sun window applications
(“tools”) are really one massive 3/4 megabyte binary? This allows
the tools to share code (there’s a lot of code in there). Lisp Machines
share code this way, too. Isn’t it nice that our workstations protect
our memory investments by sharing code.