steve@siemens.UUCP (09/17/86)
I have received enough misinformation about Dandelions and Symbolics
machines (by net and mail) that I feel forced to reply. This is not,
however, the last word I have to say. I like to keep the net in suspense,
acting like I'm saving the BIG REVELATION for later.
Key: S= Symbolics, X = Xerox Dandelions
- point against X, for S
= point for X, against S
* misinformation against X, fact in favor (my opinion of course)
? point not classifiable in previous categories
A writer who prefers to remain anonymous pointed out:
- If your system is bigger than 32 Mb, it can't be done on a Xerox machine.
- It takes a great deal of effort to get good numerical performance on X.
- X. editor is slow on big functions & lists. My opinion is that it is
bad programming style to have such large functions. However, sometimes
the application dictates and so this is a point.
* "Garbage collection is much more sophisticated on Symbolics" To my
knowledge this is absolutely false. S. talks about their garbage
collection more, but X's is better. Discuss this more later if you want.
* Preference for Zmacs with magic key sequences to load or compile portions
of a file, over Dandelion. People who never learn how to use the X system
right have this opinion. more later.
* "Symbolics system extra tools better integrated" Again, to my knowledge
this is false. I know people who say no two tools of S. work together
without modification. I have had virtually no trouble with diverse X.
tools working together.
? "S. has more tools and functions available e.g. matrix pkg." On the other
hand I have heard S. described as a "kitchen sink" system full of many
slightly different versions of the same thing.
There is a general belief that the reason the X system is around 5 - 6 Mb
vs. S. around 24 is that S. includes more tools & packages.
+ When you load in most of the biggest of the tools & packages to the X
system you still are down around 6 - 7 Mb!
+ If your network is set up reasonably, then it is trivial to load whatever
packages you want. It is very nice NOT to have junk cluttering up your
system that you don't want.
? "The difference in size reflects how much space you have for CONSes, etc."
Huh? I have 20Mb available, yet I find myself actually using less than
7Mb. My world is 7Mb. If I CONS a list 3 Mb long, my world will be 10Mb.
Royt@gatech had some "interesting" observations:
+ Performance per dollar: you can get at least 5 X machines for the cost
of a single S machine. AT LEAST. Both types prefer to be on networks
with fileservers etc., which adds overhead to both.
? X abysmally slow for baby GPS etc. My guess is that whoever ported/wrote
the software didn't know how to get performance out of the X machines.
It's not too hard, but it's not always obvious either.
= Xerox is getting on the Commonlisp bandwagon only a little late. But how
"common" is Commonlisp when window packages are machine dependent?
= For every quirk you find in Interlisp (".. Lord, that lisp seems weird to
me! I mean, comments that return values??"), I can find one in Commonlisp.
(Atoms whose print names are 1.2 for example.)
+ X has nice windows, less complicated than S. No one i know has ever crashed
a X machine by messing with the windows. Opposite for S. machine.
+ structure editor on X machine, none on S.
* "Dandelions *lack* decent file manipulation..." Wrong, comment later.
? he has bad experience with the old IP/TCP package. Me too, but the new
one works great. (The X NS protocols actually are quite good but the rest
of the world doesn't speak them :-().
? "..Typically, what I do and what other people do .. is enter a function in
the lisp window, which makes it very difficult ..." Didn't you realise
you must be doing something wrong? That's not how you enter functions!
You give other examples of how you and your cohorts don't know how to
use the Xerox system right. You're too stuck on the old C & Fortran
kinds of editing and saving stuff.
* He goes on about reliability of X being the pits. Every person I have
known who learned to use the X machine caused it to crash in various
ways, but by the time (s)he had enough experience to be able to explain
what he did to someone else, the machine no longer crashed. I guess
the X machines have a "novice detector". My understanding is that
S has its problems too.
One guy had bad experience with KEE, which was developed on X. I do not
think his experience is representative. What he did say was that it kept
popping up windows he didn't want; X systems make much more use of
sophisticated window and graphic oriented tools and interfaces than S,
but it doesn't often pop up useless windows in general.
Dave@milano thinks S offers reliable hardware, reliable software, and
good service that X doesn't. WRONG! At his site, they were obviously
doing something sytematically wrong with their machines, and they didn't
get a good repairman. I can give you horror stories about Symbolics, too,
but I have some pretty reliable points:
+ At a site I know they have around 20 S. They have sophisticated users
and they do their own board swapping. Still they have 10% downtime.
+ At my site we have very roughly 20 machine-years with X. Total downtime
less than 2 machine weeks.
+ S. has such hardware problems that a) they have a "lemon" program where
you can return your machine for a new one, b) their service contracts
are OUTRAGEOUSLY EXPENSIVE!
These lisp machines are very complex systems. If you don't have someone
teach you, who already knows the right ways to use the machine, then it
will take you more than 4 months to learn how to use it to the best
advantage. Hell, I've been using a Dandelion almost constantly for close
to three years and there are still subsystems that I only know superficially,
and which I know I could make better use of! If the same isn't true of
Symbolics it can only be because the environment is far less rich. It is
not difficult to learn these subsystems; the problem is there's just SO
MUCH to learn. Interlisp documentation was just re-done and it's 4.5 inches
thick! (Used to be only 2.25)
Finally, I will expound a little on why Xerox is better than Symbolics.
The Xerox file system and edit/debug cycle is far superior to an old-
fashioned standard system like Symbolics which has a character-oriented
editor like Zmacs. The hard part for many people to learn the Xerox file
system, is that first they have to forget what they know about editors and
files. A lot of people are religious about their editors, so this step
can be nearly impossible. Secondly, the documentation until the new version
was suitable primarily for people who already knew what was going on. That
hurt a lot. (It took me maybe 1.5 years before I really got control of the
file package, but I was trying to learn Lisp in the first place, and
everything else at the same time.) Now it's much much faster to learn.
The old notion of files and editors is like assembly language. Zmacs with
magic key sequences to compile regions etc. is like a modern, good assembler
with powerful macros and data structures and so forth. Xerox's file system
is like Fortran/Pascal/C. Ask the modern assembly programmer what he sees
in Fortranetc. and he'll say "nothing". It'll be hard for him to learn.
He's used to the finer grain of control over the machine that assembly gives
him and he doesn't understand how to take advantage of the higher level
features of the Fortranetc. language. Before you flame at me too much,
remember I am analogizing to a modern, powerful assembler not the trash
you used 5 years ago on your TRS-80. The xerox file package treats a file
as a database of function definitions, variable values, etc. and gives you
plenty of power to deal with them as databases. This note is long enough
and I don't know what else to say so I'll drop this topic somewhat unfinished
(but I will NOT give lessons on how to use the Xrox file package).
A final final note: the guy down the hall from me has used S. for some
years and now has to learn X. He isn't complaining too much. I hope he'll
post his own remarks soon, but I've got to relate one story. I wanted to
show him something, and of course when I went to run it it didn't work
right. As I spent a minute or two eradicating the bug, he was impressed
by the use of display-oriented tools on the Dandelion. He said, "Symbolics
can't even come close."
Steven J. Clark, Siemens RTL
{ihnp4!princeton or topaz}!siemens!stevedarrelj@sdcrdcf.UUCP (Darrel VanBuer) (09/19/86)
A slight echo on the Interlisp file package (partly response to earlier note
on problems using MAKEFILE, and losing a bunch of user-entered properties.
Rule 1. Users never call MAKEFILE (in 9 years of Interlisp hacking, I've
probably called it half a dozen times).
So how do you make files? I mainly use two functions:
CLEANUP() or CLEANUP(file1 file2 ...) Former does all files containing
modifications, latter only named files. The first thing CLEANUP does
is call UPDATEFILES, which is also called by:
FILES?() Reports the files which need action to have up to date
source, compiled and hardcopies, also calls UPDATEFILES, which will
engage you in a dialog asking you the location of every "new" object.
Most of the ways to define or modify objects are "noticed" by the file
package (e.g. the structure editor [DF, EF, DV ...], SETQ, PUTPROP, etc which
YOU type at top level). When an object is noticed as modified, either the
file(s) containing it are marked as needing a remake, or it gets noted as
something to ask you about later. You can write functions which play the
game by calling MARKASCHANGED as appropriate.
Two global variables interact with details of the process:
RECOMPILEDEFAULT usually EXPRS or CHANGES. I prefer the former, but CHANGES
has been the default in Interlisp-D because EXPRS didn't work before
Intermezzo.
CLEANUPOPTIONS My setting is usually (RC STF LIST) which means as part of
cleanup, recompile, with compiler flags STF (F means forget source from in
core, filepkg will automagically retrieve it if you edit, etc), and make a
new hardcopy LISTing.
For real fun with filepkg and integration with other tools, try
MASTERSCOPE(ANALYZE ALL ON file1)
MASTERSCOPE(EDIT WHERE ANY CALLS FOO)
CLEANUP()
--
Darrel J. Van Buer, PhD
System Development Corp.
2525 Colorado Ave
Santa Monica, CA 90406
(213)820-4111 x5449
...{allegra,burdvax,cbosgd,hplabs,ihnp4,orstcs,sdcsvax,ucla-cs,akgua}
!sdcrdcf!darrelj
VANBUER@USC-ECL.ARPA