[comp.soft-sys.andrew] ez and GNUemacs.

zs01+@ANDREW.CMU.EDU (Zalman Stern) (08/02/90)

Some time ago, in this newsgroup, Nathaniel Borenstein claimed that ez
predates GNUemacs. As the original author of ez, I can see no way of
justifying such a statement. I clearly remember using GNUemacs before
writing the ez file commands. The Visit File behavior of ez is stolen from
GNUemacs.

Arguments that BX, edittext, and xyzzy were out earlier are irrelevant in
that there are many earlier versions of emacs as well.

Sincerely,
Zalman Stern | Internet: zs01+@andrew.cmu.edu | Usenet: I'm soooo confused...
Information Technology Center, Carnegie Mellon, Pittsburgh, PA 15213-3890
*** Friends don't let friends program in C++ ***

nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) (08/02/90)

Excerpts from internet.info-andrew: 1-Aug-90 ez and GNUemacs. Zalman
Stern@andrew.cmu. (639)

> Some time ago, in this newsgroup, Nathaniel Borenstein claimed that ez
> predates GNUemacs. As the original author of ez, I can see no way of
> justifying such a statement. I clearly remember using GNUemacs before
> writing the ez file commands. The Visit File behavior of ez is stolen
> from GNUemacs.

> Arguments that BX, edittext, and xyzzy were out earlier are irrelevant
> in that there are many earlier versions of emacs as well.

Well, those are the arguments I would make, but I think they are
relevant because it was my impression that what you're calling ez was an
evolutionary development, not a whole new program.  I believe there is
still code in ez that is recognizably code from the original edittext
and xyzzy; certainly there is a lot left over from bx.  Gnumacs, on the
other hand, was a complete rewrite, as I understand it, in order to
follow the GNU philosophy of software unencumbered by any previous
copyright.

However, I recognize that this is a pointless thing to quibble about. 
The real point of the discussion is that complaining that Andrew is not
Gnumacs compatible is silly, becuase Gnumacs was not relevant during its
design.  Even if you view ez as a completely new program, which I don't,
it was still closely following the design that was established with the
previous Andrew editors.

bader+@ANDREW.CMU.EDU (Miles Bader) (08/02/90)

Nathaniel Borenstein <nsb@thumper.bellcore.com> writes:
> Well, those are the arguments I would make, but I think they are
> relevant because it was my impression that what you're calling ez was an
> evolutionary development, not a whole new program.  I believe there is
> still code in ez that is recognizably code from the original edittext
> and xyzzy; certainly there is a lot left over from bx.  Gnumacs, on the
> other hand, was a complete rewrite, as I understand it, in order to
> follow the GNU philosophy of software unencumbered by any previous
> copyright.

Apparently, you've never looked too closely at the code for gnu-emacs...

-Miles

zs01+@ANDREW.CMU.EDU (Zalman Stern) (08/04/90)

Nathaniel Borenstein <nsb@thumper.bellcore.com> writes:
> Well, those are the arguments I would make, but I think they are
> relevant because it was my impression that what you're calling ez was an
> evolutionary development, not a whole new program.  I believe there is
> still code in ez that is recognizably code from the original edittext
> and xyzzy; certainly there is a lot left over from bx.  Gnumacs, on the
> other hand, was a complete rewrite, as I understand it, in order to
> follow the GNU philosophy of software unencumbered by any previous
> copyright.

\begin{flame}

Your impression is wrong. I've also run into people who claim that Mach is
just Accent run through a Pascal to C translator. I find such statements
extremely galling in that they deny good work done by good people. Imagine
how you would feel if someone said "Messages is just BAGS translated into C
with some user interface enhancements picked up from ReadMail and
ReadNews." (For the info-andrew readership: BAGS was a MockLISP mail/bboard
reader written by Nathaniel before he came to the ITC. ReadMail and
ReadNews were two programs written by Tom Peters and are to edittext as
messages is to ez.  Messages bears little relationship to either of these
three programs.)

The redraw code and editing commands for text were completely rewritten by
Mike Kazar going from edittext to bx. This code was significantly cleaned
up (i.e. made readable by mere mortals) by Andy Palay in the conversion to
class. Later Andy add BitBlit scrolling and smooth inverted rectangle
cursors. (After which point he might as well have rewritten it for all the
original code you can recognize.) Tom Neuendorffer eliminated whole line
redraw. Since then I have fixed a number of bugs, but not rewritten much.

The entire style handling code was significantly redesigned by Mark Sherman
and Maria Wadlow about the time we went from bx to ez. A lot of code had to
be written to support datastream and the different template model. Text
commands were rewritten completely By Mike Kazar for bx and somewhat
reworked by Mike and myself for ez. (Tom N. added inset commands.) Printing
stayed much the same from edittext until Jaap Akkerhuis and Tom N. redid it
last year. Remaining parts of ez are things like file/buffer handling and
ezapp all of which I wrote from scratch. In addition, many other things
like the current event handling model, frame, keymaps and proctables (done
by David Nichols) came into being about the time of ez.

\end{flame}

1) Almost all the code was rewritten going from edittext to bx to ez. It
doesn't matter anyway since a lot of the technology involved is well
understood and doesn't change much in user perceptible ways.

2) We should be discussing user interface concepts instead of what the C
code looks like. GNU emacs inherits >90% of its user interface from
previous versions of emacs. Ez inherits somewhat less of its user interface
from previous ITC editors. (Edittext did not have multiple buffers for
example.)

3) We knew about emacs (GNU and otherwise) when we did ez. We considered it
of some but not overriding importance for the following reasons:
   - ATKs main feature was to be extensible to editing different graphical
     media. Emacs only does text in a single fixed width font.
   - We were doing a user interface toolkit not just an editor. This placed
     demands of generality upon us that emacs did not have to meet.
   - We were designing an editor for novice users. Many people thought
     MacWrite was a better model than emacs. (Being CS geeks, we put as
     much of emacs in as we could anyway.)
   - Memory was supposed to be tight. Writing it in LISP was not an option.

4) Of the above items, I believe ATK is:
    - a good research (i.e. throwaway) system for extensible media
    - the best designed X11 toolkit, but too flaky and incomplete to
      really use
    - a compromise that doesn't work wonderfully well for novices or
      hackers. (See flaky and incomplete above.)
    - A failure at memory conservation.

If I had known that our primary audience would be CS professionals and that
our delusions of generality were doomed to fail anyway, I would have done
things differently.

Sincerely,
Zalman Stern | Internet: zs01+@andrew.cmu.edu | Usenet: I'm soooo confused...
Information Technology Center, Carnegie Mellon, Pittsburgh, PA 15213-3890
(This message was composed and mailed using BatMail under GNUemacs.)

nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) (08/04/90)

Hey, if I was wrong, I'm sorry.  I was just going by what I thought I knew.

Excerpts from internet.info-andrew: 4-Aug-90 Re: ez and GNUemacs. Zalman
Stern@andrew.cmu. (4457)

> I find such statements extremely galling in that they deny good work
> done by good people.  Imagine how you would feel if someone said
> "Messages is just BAGS translated into C with some user interface
> enhancements picked up from ReadMail and ReadNews."

To be totally honest, I don't think that would be an unfair
characterization, although I'd also point to a few additional
innovations such as the messageserver/client architecture and the
specialized active messages.  But then, I don't see anything wrong with
seeing my work as evolutionary rather than revolutionary.  In fact, in
general I think it's a good thing.  But if you'd rather maintain that ez
is all new, that's fine with me.  To my mind, actually, that attitude
explains a lot.

However, the fact that you could explain things like "The redraw code
and editing commands for text were completely rewritten by Mike Kazar
going from edittext to bx. " indicates, to me, that lots of other things
weren't rewritten at that point.    I don't deny that most of the code
has changed completely from the early days, but I don't think there was
any point at which you threw out everything and started over from
scratch, which is all I was saying.  I wasn't denying that a lot of good
work went in to the evolution from xyzzy to ez -- obviously it did.  But
it happened gradually, in stages, that's all.

For the record, I think this is an extremely stupid thing for us to be
arguing about.  -- Nathaniel