[fa.editor-p] Learning Z vs Zmacs

daemon@ucbvax.UUCP (09/21/83)

From JQJ@SU-SCORE.ARPA  Wed Sep 21 00:12:58 1983
Please refrain from making the assumption that features of the Lisp
machine you got from Symbolics were done BY Symbolics.  You are
inadvertently spreading their false advertising.  Their p.r. speaks
as if they invented the Lisp machine and everything on it.  This is
of course not true; the Lisp machine was invented by Greenblatt, who
founded LMI, and Lisp machines from LMI run a system that is mostly
the same as those from Symbolics.

The MIT system, which LMI uses, has several improvements relating to
the editor.  For example, Ztop and the Lisp (Edit) window really work,
and provide all the session management facilities that Dyer describes.

Many other features of Z that he mentions are also present in Zmacs,
and have been for ages.  The main problem is that there is no document
that describes any of the features that Zmacs has but Emacs doesn't.
For example, it is quite possible to take characters out of the text
to put them into a command argument.

Cursor motion can always be done in Emacs with the four basic commands
forward/backward character/line, which are no more complicated than
the Z cursor commands.  You don't need to memorize any more commands
than you do in Z (except that those other commands are useful).

The reason that these commands are not normally on arrow keys is that
1) some terminals don't have arrow keys and 2) the arrow keys have
problems.  There is no place for them in the character set; they use
sequences which you could also get by typing legitimate sequences of
other keys.  And these sequences are different on different
terminals.

On various particular terminal types, Emacs extensions exist to
redefine the arrow keys to do cursor motion, but it is always
terminal-dependent.  In Zmacs it might be reasonable to make the
hand-up, etc., characters be those four commands.  I guess no Lisp
machine hacker ever thought it mattered.

I would be driven to distraction if any random motion of the mouse
interfered with what I was doing, in any way whatever, when I was not
trying to use the mouse.  I am glad that the mouse won't do anything
unless I click on it.

daemon@ucbvax.UUCP (09/21/83)

From JQJ@SU-SCORE.ARPA  Wed Sep 21 00:43:49 1983
Michael,

	I find myself interested & rather suprised by what you've said
wrt Z &  EMACS. The idea of going from novice to FLUENT in 20 mins.
is incredible, esp. when you mention the existance of like 30+ commands,
mode switching & non-stream orientation. Futher, you talk freely about
many functions which I have specifically avoided in the project described
below. Thus I wish to know more.

			------------

	As part of a Computational Linguistics project at U Penn
where I was last year I did a series of experiments involving teaching
novices to use EMACS (Modified Gosling's VAX-EMACS) under very controlled
circumstances. The objective was to collect transcripts of people 
communicating in an EXPERT-NOVICE situation & make observations on
modes of failure.

	Experimental layout: 

o	1 hr. of supervised training (this is a computer, this is
	a file, here's how we start EMACS, These are the keys for: 
	Up, Down, Left, Right, Page, insert, delete, & exit),

o	The novice was given a specific task to do (Fix this text), 
	informed that it was designed to make them learn new commands 
	& concepts  ("If you find yourself having to do the same 
	thing ten times in a row, there's an easier way to do it.")

o	EMACS was divided into two windows, the 5-line bottom window
	being a TALK subjob to another terminal behind which a relative
	expert sat. The expert sat in another room and read a book
	untill the novice asked a question.

o	The novice was expected to know the 15 or so commands taught
	the first day (This was on a Concept-100 terminal, so all
	movements were on arrow keys.), and expected to learn another
	5-10 commands on each of three subsequent app. 1 hr. sessions. 

o	Absolutely every unused command was disabled. (This proved 
	essential, in the test runs I left a couple things in and ,
	by god, they found them.)

o	Subjects were all highly self motivated, most of them being
	students in CS or Linguistics. They were (of course) all quite
	successful in learning what they were after, a nice side
	effect. (The one drop-out was a secretary who was told she HAD
	to learn to use the computer.)

o	Experts were ex-subjects who spent an extra half-hour with me
	going over everything they had done & needed to know for the
	task. How THEY explained anything was their problem.


	The thrust of my project was analysing the transcript generated
(nice thing about the experiment, the transcript was free. If you've ever
tried recording a verbal transcript...), and even with a mere ten subjects
I got PLENTY of material.

	Linguistically I learned quite a bit (including the fact that I
am not cut out to be a linguist), so the experiment was an unqualified
success. More, I learned a fair amount about teaching, setting up and
running experiments involving humans.

	What's of significence here, is that I thusly possess a great
deal of experience in teaching editors under very tightly controlled
conditions, both acting as expert & observer.

	Specific observations included such things as:

o	A well defined task with a limited number of clearly 
	stated objectives IS essential, and will cut learning
	time by at least 2. (Included in this is repetition,
	"Not another paragraph to justify! Oh well, --M-C-J--")

o	It is my OPINION that a task that allows the novice to
	'discover' commands is superior to a lecture (motivation
	& all that).

o	Given any opportunity to misunderstand, the novice will,
	AND SO WILL THE EXPERT. If informed before hand that the
	other person is INTENTIONALLY going to search for an alternate
	meaning to a statement, things improve vastly.

o	If you don't let them know something is difficult,
	they will probably just do it & never realize it's hard.


			----------------

	Now, none of these observations are at all specific to any
editor, nor is the experimental setup (other then the fact you can't
create subjobs in most editors). So it would be very interesting to
compare such experiments across editors. I would be very interested 
in knowing what experience others have had who have done any type 
of well-controlled teaching of an editor.



-Bil

(Michael: I should be passing by New Haven a few days from now,
any chance I could visit? I would love to see Z for real & get a chance 
to exchange thoughts.)
-------
-------

daemon@ucbvax.UUCP (09/25/83)

From JQJ@SU-SCORE.ARPA  Sun Sep 25 00:17:08 1983

	From: RMS%MIT-OZ@MIT-MC
	Please refrain from making the assumption that features of the Lisp
	machine you got from Symbolics were done BY Symbolics.  You are
	inadvertently spreading their false advertising.

A point for the record; Despite RMS flamage, the original lisp
machine lardware was a product of the MIT-AI lab, principally
designed by Greenblatt, Knight, and Holloway; in proportions unknown
to me.  They also collaborated on other lab products of the period.

The current lisp machine software was also developed at the MIT-AI
lab, by a multitude of grad students and staff hackers, many of whom
were founders of Symbolics.  Greenblatt was the principal founder of
LMI.

At the time Symbolics and LMI were founded, MIT licensed the existing
hardware and software to both companies, presumably on mutually
beneficial terms.  There are two lisp machine companies rather than
one due to the random variability of the universe, which does not
include malice on the part of anyone.


[Editor's note:  since the relative merits of Symbolics and LMI as
 manufacturers of Lisp machines and as true heirs to the "MIT Lisp
 Machine" have little to do with editing, I will take the liberty of
 censoring further comments on this subject.
                                                /jq ]

daemon@ucbvax.UUCP (09/25/83)

From JQJ@SU-SCORE.ARPA  Sun Sep 25 00:32:28 1983
    Date:  6 Sep 1983 0616-EDT
    From: RMS%MIT-OZ@MIT-MC
    The MIT system, which LMI uses, has several improvements relating to
    the editor.  For example, Ztop and the Lisp (Edit) window really work,
    and provide all the session management facilities that Dyer describes.

This just isn't true, except for a limited number of subsystems that
can be run in any window.  Z succeeds because all the subsystems that
it is concerned with CAN be.  However, I think part of the complaint
was that so much of the Lisp Machine environment could not be unified
by such an interface.

I agree with the rest of what you say about Zmacs/Emacs vs Z.

daemon@ucbvax.UUCP (09/25/83)

From JQJ@SU-SCORE.ARPA  Sun Sep 25 00:36:53 1983
I stand by the statement that Dyer's session management complaints,
as I understand them, are solved in the MIT Lisp machine system.
It is true that operations on weird windows is not included in this.
How could one, for example, yank back a menu mouse click and edit it?
But insofar as the Lisp machine system has commands, they are
things you can type at a Lisp listener; and these and their output
can be edited and reinput using the Lisp (Edit) window which
Symbolics chose to flush and I chose to fix instead.

[Editor's note:  for the benefit of the general reader (e.g. me)
 could someone state the RWK/RMS debate more precisely?  It seems to
 me that they differ in their conceptualization of the purpose of a
 display, with RMS asserting that it is multi-purpose, with several
 "modes" of output -- representations of text, status messages, etc.,
 while RWK and Dyer wish to treat characters on the display
 modelessly.  Is there in fact a naatural typology of display
 uses?			  /jq ]