The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] Unix taste (Re:  terminal - just for fun)
@ 2014-08-02 14:28 Doug McIlroy
  2014-08-02 14:00 ` Larry McVoy
                   ` (2 more replies)
  0 siblings, 3 replies; 32+ messages in thread
From: Doug McIlroy @ 2014-08-02 14:28 UTC (permalink / raw)


> To each their own.

Indeed.

> As a Vi user, nothing beats having Esc on the home row.

A symptom of why I have always detested emacs and vi. With ^D, ^C,
and ^\, Unix has more than enough mystery chords to learn. Emacs
and vi raised that number to a high power--an interface at least
as arcane and disorganized as the DD card in OS 360--baroque
efflorescences totally out of harmony with the spirit of Unix.

(Perhaps one could liken learning vi to learning how to finger
the flute, but the flute pays off with beautiful music. To put the
worst face on vi, it "pays off" only by promoting frantic tinkering.)

A modern-day analog of the undisciplined exuberance of emacs and vi:
for a good time on linux try
        less --help | wc

Does comment on taste belong in a discussion of history? I think
so. Unix was born of a taste for achieving big power by small
means rather than by unbounded accumulation of facilities. But
evolution, including the evolution of Unix, does not work that
way. An interesting question is how the corrective of taste manages
ever to recenter the exuberance of evolution. The birth of Unix shows
it can happen. When will it happen again? Can one cite small-scale
examples that gained traction within the larger evolution of Unix?

Doug



^ permalink raw reply	[flat|nested] 32+ messages in thread
* [TUHS] Unix taste (Re:  terminal - just for fun)
@ 2014-08-02 16:47 Noel Chiappa
  2014-08-02 18:51 ` Ian King
  0 siblings, 1 reply; 32+ messages in thread
From: Noel Chiappa @ 2014-08-02 16:47 UTC (permalink / raw)


    > From: Doug McIlroy <doug at cs.dartmouth.edu>

    > A symptom of why I have always detested emacs and vi. With ^D, ^C, and
    > ^\, Unix has more than enough mystery chords to learn. Emacs and vi
    > raised that number to a high power--an interface at least as arcane and
    > disorganized as the DD card in OS 360--baroque efflorescences totally
    > out of harmony with the spirit of Unix.

I will agree that the Emacs user interface is not simple - although there are
levels, and one can start out e.g. without knowing the commands to move by
word, and get by with the commands to move by character - and of course
nowadays, the arrows, etc, keys on keyboards are bound to the appropriate
commands, for novices.

But it's a subtle debate; yes, it's not for everyone, but i) as an
application, not everyone has to use it (unlike a kernel), and ii) as the
editor is the principal tool which most programmers spend hours a day using,
it is not insensible to have a more complex but powerful tool which takes a
while to fully master. (Like playing a violin...)

Back on V6, we started using one written by someone at BBN (memory fails me as
to exactly who), and it improved my productivity immensely (with 'WYSIWG'
editing - i.e. you always see the current contents of the buffer, multiple
buffers, multiple windows, etc).

I had been using 'ed' (although I had access to Emacs on the ITS machines),
and although I was (and remain) fairly skilled at 'ed', the factors I just
listed are immense, IMO. Being able to see the code as I work on it really,
really helps (for me, at least).

But a lot of that is orthogonal to Emacs command interface; you can have
'WYSIWYG', multiple buffers, etc with a wholly different command interface,
and get much the same benefit. (E.g.  uSoft Word has most of those; real
WYSIWG [i.e. with multiple fonts], multiple files open at once, etc, etc.)

Does something like Word produce the same reaction for you? I don't use it
much, but my wife does (she's an engineer, and uses it to write papers), and
its complexity drives her crazy sometimes.


As for the size of Emacs, everyone needs to distinguish between GNU Emacs, and
Emacs-like editors. Just as GCC is a beast, but other C compilers are and were
much smaller, there are small Emacses out there.

Back on V6 (on a PDP-11, of course), it had to fit into 64KB; the one we used
didn't have the kind of extensibility common in them now, but it was still
a much better tool for me than 'ed'.

As I recall the performance was pretty good (albeit it chewed CPU time, since
it woke up on every character - Multics had an Emacs which tried to avoid
that, and only woke up on non-printing characters, and used system echoing for
the others). I don't know for sure (I don't have the source to hand at the
moment - that's one of the things I hope to recover if/when I can read those
backup tapes), but I suspect that it 'windowed' files (i.e. didn't read the
whole thing in); with the 65KB address space of the 11, that would be almost
inevitable.

I have been using another Emacs, Epsilon, for almost 30 years now; it started
as basically Emacs for MS-DOS, and later became Emacs for Windows, and it is
small and very fast. The Windows executable is about 250KB, and it loads a
'state file' (mostly interpreted 'compiled' intermediate code, written in
something that's 99.2% 'C', in which a lot of the editor is actually written)
of about 200K (for mine, which has a lot of extensions I wrote). It starts
fast, and runs blindingly fast. It also uses the file 'windowing' techniques,
and can handle much larger files than its address space (this dates back to
its MS-DOS days).

So Emacs != big (at least, not necessarily).


    > A modern-day analog of the undisciplined exuberance of emacs and vi:
    > for a good time on linux try

I basically agree with you on this; I want to go away and collect my thoughts
before responding, though.

	Noel



^ permalink raw reply	[flat|nested] 32+ messages in thread
* [TUHS] Unix taste (Re:  terminal - just for fun)
@ 2014-08-02 21:18 Noel Chiappa
  2014-08-02 23:44 ` A. P. Garcia
  0 siblings, 1 reply; 32+ messages in thread
From: Noel Chiappa @ 2014-08-02 21:18 UTC (permalink / raw)


    > From: Benjamin Huntsman <BHuntsman at mail2.cu-portland.edu>

    > I thought it stood for Escape-Meta-Alt-Control-Shift :)

    > From: Dave Horsfall <dave at horsfall.org>

    > EMACS - Editor too large

Those are both pretty funny!


BTW, Epsilon (that 250KB Emacs that I was raving about) not only runs under
Windows, it also runs under Linux, Mac OS, FreeBSD, etc. Here:

    http://lugaru.com/

I can't say enough good things about it (hence my 30-year addiction to it).
If you want an Emacs clone that is very small; very fast; and wildly
extensible and modifiable (it comes with almost all the source), in C
(effectively); this is the one.

	Noel



^ permalink raw reply	[flat|nested] 32+ messages in thread
* [TUHS] Unix taste (Re: terminal - just for fun)
@ 2014-08-03  0:48 Noel Chiappa
  2014-08-03  8:00 ` A. P. Garcia
  0 siblings, 1 reply; 32+ messages in thread
From: Noel Chiappa @ 2014-08-03  0:48 UTC (permalink / raw)


    > From: "A. P. Garcia" <a.phillip.garcia at gmail.com>

    > Being so small, I expected the editor to lack a scripting language.

Well, there is a companion 'compiler' which converts extension source into
the intermediate form (byte-code) which is interpreted by the editor. But
it's even smaller (67KB!) and as fast as the editor itself.

    > I was pleasantly surprised that it does have one, and that it's a c
    > derivative ... "Extensible and modifiable" doesn't always mean the same
    > thing to everyone, and well, you're a kernel hacker.

Take a quick look at a source file, e.g. one of mine:

  http://ana-3.lcs.mit.edu/~jnc/tech/cmd.e

and you'll see i) what it's like (except for a few new editing-specific
keywords, such as 'on <key>' in function definitions, it's pretty much C),
and ii) it will give you a sense of the kind of things one writes in it, and
how easy it is to do so.

The underlying run-time basically just provides buffer, display, etc
primitives, and pretty much all the actual editor commands are written in the
'extension' languge, even simple things like 'forward character' (^F), etc.
The complete manual is available online, the run-time system is described
here:

  http://www.lugaru.com/man/Primitives.and.EEL.Subroutines.html

Epsilon comes (as of a few versions back, I haven't bothered to upgrade) with
about 22K lines of source, which is the bulk of the actual editor; that turns
into about 190KB of intermediate code.

	Noel




^ permalink raw reply	[flat|nested] 32+ messages in thread
* [TUHS] Unix taste (Re: terminal - just for fun)
@ 2014-08-03 11:49 Noel Chiappa
  2014-08-03 12:14 ` Steve Nickolas
                   ` (2 more replies)
  0 siblings, 3 replies; 32+ messages in thread
From: Noel Chiappa @ 2014-08-03 11:49 UTC (permalink / raw)


    > From: "A. P. Garcia" <a.phillip.garcia at gmail.com>

    > the spirit of emacs without the bloat :-)

Exactly. I've often wondered what the heck exactly it is that GNU Emacs, GCC,
etc are all doing with those megabytes of code. (In part, probably all those
options: "Options. We've got lots of them. So many in fact, that you need two
strong people to carry the documentation around.", as that classic hack says.
But there's no way the options alone can explain it all.)

The thing is that it's not just aesthetics that makes large programs bad;
there are very good practical reasons why they are bad, too. The 'takes more
resources' isn't such a big deal today, because memory is massive, and
there's a ton of computing power to be thrown at things. (Although I'm always
amazed at how the active content in Web pages seems to run incredibly slowly
on all but the very latest and greatest machines. WTF are they doing?)

But more code = more material that someone new has to understand before they
can make some change (and long-lived code is always being changed/upgraded by
new people). And when people understand a system poorly, their changes tend
to be 'a bag on the side', and that's the kind of 'code cancer' that tends to
kill systems in the long run. More code also is also more places where there
can be bugs (especially when it's changed by someone who understands it
poorly, repeat previous comment).

Etc, etc. And those will never go away - human brain power is finite, and
unlike hardware, not expanding.

There's just no reason to have N megabytes of code when .N will do. (I've
often thought we ought to make new programmers serve an apprenticeship of a
year of two on a PDP-11 - to teach them to 'think small', and to realize you
_can_ do a lot in a small space.)

	Noel



^ permalink raw reply	[flat|nested] 32+ messages in thread
* [TUHS] Unix taste (Re: terminal - just for fun)
@ 2014-08-03 16:48 Noel Chiappa
  2014-08-03 17:09 ` John Cowan
  0 siblings, 1 reply; 32+ messages in thread
From: Noel Chiappa @ 2014-08-03 16:48 UTC (permalink / raw)


    > From: John Cowan <cowan at mercury.ccil.org>

    > because of all the Elisp code it ships with

So why is /usr/bin/emacs 4.5 megabytes?

    > That's basically just the kind of peeving that objects to the use of
    > computers as calculators and spelling checkers.

I just gave several good reasons why large programs (well, technically,
systems) are bad. Are you saying those reasons are fallacious?

	Noel



^ permalink raw reply	[flat|nested] 32+ messages in thread
* [TUHS]  Unix taste (Re:  terminal - just for fun)
@ 2014-08-04  2:54 Norman Wilson
  2014-08-04  3:11 ` Lyndon Nerenberg
  0 siblings, 1 reply; 32+ messages in thread
From: Norman Wilson @ 2014-08-04  2:54 UTC (permalink / raw)


Doug McIlroy:

  A symptom of why I have always detested emacs and vi. With ^D, ^C,
  and ^\, Unix has more than enough mystery chords to learn.

====

What is this ^C mystery chord?

Or can it be that I am actually more wedded to the past than
Doug, in that I still use DEL as my interrupt character?

And, for that matter, @ for kill (though in the modern world
one has to type @ often enough to require learning a different
modern-world mystery chord, ^V).

I break with the past for character-erase, though: backspace,
not #.

Norman Wilson
Toronto ON



^ permalink raw reply	[flat|nested] 32+ messages in thread
* [TUHS] Unix taste (Re:  terminal - just for fun)
@ 2014-08-04 20:21 Norman Wilson
  2014-08-04 22:24 ` A. P. Garcia
  0 siblings, 1 reply; 32+ messages in thread
From: Norman Wilson @ 2014-08-04 20:21 UTC (permalink / raw)


Larry McVoy:

  Looking at git like that is sort of like looking at the size of
  a dynamically linked app.  Ya gotta add in libc and all the extensions
  people use to make it not suck.

=====

In which case one should also add the size of the kernel, or at
least the code paths exercised by a given program.

Not to mention the layers of window systems, networking, desktops,
message buses, name-space managers, programs to emulate 40-year-old
terminal hardware, flashy icons, and so on.

I say all this to underscore Larry's point, not to dispute it.

Everything has gotten more complicated.  Some of the complexity
involves reasonable tradeoffs (the move toward replacing binary
interfaces with readable text where space and time are nowhere
near critical, like the /proc and /sys trees in modern Linux).
Some reflects the more-complex world we live in (networking).
But a lot of it seems, to my mind that felt really at home when
it first settled into UNIX in 1981, just plain tasteless.

There are certainly legitimate differences in aesthetic taste
involved, though.  I think taste becomes technically important
when it can be mapped onto real differences in how easily a
program can be understood, whether its innards or its external
interface; how easily the program can adapt to different tasks
or environments; and so on.

Norman Wilson
Toronto ON



^ permalink raw reply	[flat|nested] 32+ messages in thread
* [TUHS] Unix taste (Re:  terminal - just for fun)
@ 2014-08-06 22:19 Norman Wilson
  0 siblings, 0 replies; 32+ messages in thread
From: Norman Wilson @ 2014-08-06 22:19 UTC (permalink / raw)


Lyndon Nerenberg:

  Do you still consider '^' the shell's inter-command pipe character?

======

No.  By the time I first used UNIX, | was well-established as
the official pipeline character; ^ was just a quirky synonym.
I had the impression somehow that ^ was there just to make
life easier on the Model 33 Teletype, which had no | key.

Digging into old manuals, ^ and | appear simultaneously, in
sh(1) in the Fourth Edition.  Pipelines first appeared in
3/e, though with a clumsier syntax (not supported by
any current shell I know): where we would now type
	ls | wc
the original syntax was
	ls > wc >
The trailing > was required to tell the shell to make a pipeline
of the two commands, rather than to redirect output to a file
named wc.  One could of course redirect the final command's
output to a file as well:
	ls > wc > filecount

Even clumsier: where we would now type
	ls | pr -h 'Look at all these files!'
the 3/e shell expected
	ls > "pr -h 'Look at all these files!'" >
because its parser bound > to only the single following word.

The original syntax could be reversed too:
	wc < ls <
The manual implies this was required if the pipeline's
ultimate input came from a file.  Maybe someone with more
energy than I have right now can dig out the source code
and see.

I was originally going to use an example like
	who | grep 'r.*' | wc -l
but the old-style version would be anachronistic.  There
was no grep yet in 3/e, and wc took no arguments.
	
I do still have the habit of quoting ^ in command arguments,
but that's still necessary on a few current systems; e.g.
/bin/sh on Solaris 10.  Fortunately, that makes it easier
to remember to quote ! as well, something required by the
clumsy command-history mechanism some people like but I don't.
(I usually turn off history but occasionally it gets turned on
by accident anyway.)

Norman Wilson
Toronto ON



^ permalink raw reply	[flat|nested] 32+ messages in thread
* [TUHS] Unix taste (Re:  terminal - just for fun)
@ 2014-08-06 22:24 Norman Wilson
  0 siblings, 0 replies; 32+ messages in thread
From: Norman Wilson @ 2014-08-06 22:24 UTC (permalink / raw)


Davwe Horsfall:

  I was surprised when "chdir" became "cd", but I suppose it fits the 
  philosophy of 2-letter commands.

======

Don't forget that the original spelling, in the PDP-7 UNIX that
had no published manual, was ch.

The 1/e manual spells it chdir.  I remember that in one of
Dennis's retrospective papers, he remarks on the change, and
says he can't remember why.

I once asked in the UNIX room if anyone could recall why ch
changed to chdir.  Someone, I forget who, suggested it was
because the working directory was the only thing that could
be changed: no chmod or chown in the PDP-7 days.  I don't know
whether that's true.

Norman Wilson
Toronto ON



^ permalink raw reply	[flat|nested] 32+ messages in thread
end of thread, other threads:[~2014-08-06 22:24 UTC | newest]

Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-08-02 14:28 [TUHS] Unix taste (Re: terminal - just for fun) Doug McIlroy
2014-08-02 14:00 ` Larry McVoy
2014-08-02 15:51   ` Steve Nickolas
2014-08-02 16:07     ` John Cowan
2014-08-02 17:28     ` Benjamin Huntsman
2014-08-02 19:50     ` Dave Horsfall
2014-08-02 16:04 ` Diomidis Spinellis
2014-08-02 16:03   ` Larry McVoy
2014-08-02 19:36 ` Dave Horsfall
2014-08-02 16:47 Noel Chiappa
2014-08-02 18:51 ` Ian King
2014-08-02 21:18 Noel Chiappa
2014-08-02 23:44 ` A. P. Garcia
2014-08-03  0:48 Noel Chiappa
2014-08-03  8:00 ` A. P. Garcia
2014-08-03 11:49 Noel Chiappa
2014-08-03 12:14 ` Steve Nickolas
2014-08-03 16:26 ` John Cowan
2014-08-04 13:59 ` Tim Bradshaw
2014-08-04 14:53   ` A. P. Garcia
2014-08-03 16:48 Noel Chiappa
2014-08-03 17:09 ` John Cowan
2014-08-04  2:54 Norman Wilson
2014-08-04  3:11 ` Lyndon Nerenberg
2014-08-04  7:04   ` Dave Horsfall
2014-08-04  9:12     ` Steve Nickolas
2014-08-04 20:21 Norman Wilson
2014-08-04 22:24 ` A. P. Garcia
2014-08-05  2:41   ` Andy Kosela
2014-08-05  3:32     ` Warner Losh
2014-08-06 22:19 Norman Wilson
2014-08-06 22:24 Norman Wilson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).