From: utzoo!decvax!ucbvax!C70:editor-people
Newsgroups: fa.editor-p
Title: evaluating editors
Article-I.D.: ucb.1233
Posted: Tue Jun  1 14:51:43 1982
Received: Wed Jun  2 02:56:33 1982

>From reid@Shasta@Sumex-Aim Tue Jun  1 12:28:30 1982
The issue of getting users for text editors, and of Yale's isolation,
is important, and I'd like to comment on it a bit.

In this systems business of ours, it is extremely difficult to evaluate
the quality of a piece of work. There are no mathematical proofs to
read through, no pages of data and graphs to peruse, no airtight
physics experiments that can be run to check hypotheses. Instead we
rely on our designers' instincts, evaluating systems as we explore
them. If a system is good, we might use it, steal its ideas by copying
it, rave about it to our friends, or even in some cases abandon
everything we had been doing to make the incompatible change to the new
system. If a system is bad, we might ignore it, poke fun at it, flame
at how ignorant it is, or perhaps try to evaluate why it is bad so that
we (collectively) do not make that mistake again. Sometimes systems are
bad because they are based on bad models; other times they are bad
because they are programmed badly; perhaps they are bad because they
are internally inconsistent. There are many reasons that systems can be
good or bad.

In about 1976, or thereabouts, we at CMU (where I was at the time) got
a copy of the source and documentation for the Yale Editor "E". Craig
Everhart and I struggled valiantly to get it running, and after burning
the better part of a month on it, we gave up. It was written to run
under Tops-10, but it assumed the existence of very extensive changes
to the monitor, including the dreaded SCNSER. It was politically
unacceptable at CMU to make such major and incompatible changes to the
monitor, and it just wasn't going to work without them, so we stopped.
"E" also was written to use a particular terminal (I forget the brand)
and no other, but the manufacturer of that terminal had gone out of
business. So we couldn't even dial Yale long distance and use the
editor over the phone: we didn't have the right brand of terminals. So
despite our interest in exploring this interesting-looking editor, we
were not able to evaluate it properly because we could not use it.

At about that same time, give or take half a year, the EMACS editor
started appearing on TOPS-20 systems around the network. I had access
to SRI-KL, and EMACS supported all of the various terminals that were
around. I was able to use EMACS, learn it, and assimilate its ideas.

Naturally I think that EMACS is the better of the two editors, because
I was able to use EMACS and not just hear about it. When I teach
students about text editors, I include the EMACS model of editing as a
major focus, and I don't even mention the existence of either "E" or
"Z" from Yale, despite my beliefs that they might actually be good
editors.

Now my primary computing comes from a VAX Unix, Shasta, and on that
system we can run three worthwhile editors: Jim Gosling's EMACS, Rand's E
(a.k.a. NED), and Bill Joy's VI. I don't know who at Rand is the main
force behind E. And as I think and talk about editors, it is very
convenient to be able to draw examples from these three working models.
 From what I've heard about Yale's Z, its editing model is fairly
similar to Rand's E, but since Rand's E is exportable and fairly
universal, while Yale's Z is not, I will probably end up associating
and attributing those ideas to Rand and not to Yale.

The moral of my ramble is this: if what you are trying to do is to
write a good editor for your own people to use, then you are free to do
whatever you want. If what you are trying to do is influence the
opinion of the C.S. research community, and hence the directions and
ideas of future editors, you have to make your system available to them
to be evaluated. These people are not fooled by rhetoric nor persuaded
by hearsay.

Brian Reid