[TUHS] Unix taste (Re: terminal - just for fun)

[TUHS] Unix taste (Re: terminal - just for fun)

[Norman Wilson]

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

[TUHS] Unix taste (Re: terminal - just for fun)

[Norman Wilson]

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

[TUHS] Unix taste (Re: terminal - just for fun)

[Warner Losh]

On Aug 4, 2014, at 8:41 PM, Andy Kosela <akosela at andykosela.com> wrote:

> On Mon, Aug 4, 2014 at 5:24 PM, A. P. Garcia <a.phillip.garcia at gmail.com> wrote:
>> 
>> On Aug 4, 2014 3:22 PM, "Norman Wilson" <norman at oclsc.org> wrote:
>> 
>> <snip>
>> 
>> 
>>> 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).
>> <snip>
>> 
>> To digress from the main topic, I realize that's just one example, but
>> here's a counterpoint to it:
>> 
>> We in Solaris designed /proc as a tool for developers to build innovative
>> solutions, not an end-user interface. The Linux community believes that 'cat
>> /proc/self/maps' is the best user interface, while we believe that pmap(1)
>> is right answer. The reason for this is that mdb(1), truss(1), dtrace(1M)
>> and a host of other tools all make use of this same information. It would be
>> a waste of time to take binary information in the kernel, convert it to
>> text, and then have the userland components all write their own (error
>> prone) parsing routines to convert this information back into a custom
>> binary form. Plus, we can change the options and output format of pmap
>> without breaking other applications that depend on the contents of /proc.
>> 
>> [ https://blogs.oracle.com/eschrock/entry/the_power_of_proc]
> 
> Interestingly, we at FreeBSD got rid of /proc in favor of procstat(1)
> and ptrace(2).  I am still not too sure if it was the Right Thing(r)
> to do though.  The decision was more based on the premise that
> procfs(4) was neglected in recent years than on anything else[0].
> 
> [0] http://freebsd.1045724.n5.nabble.com/Why-is-procfs-deprecated-in-favor-of-procstat-td4028960.html

FreeBSD also chose to export most nuggets of data from the kernel that are
covered by /proc in linux via sysctls. This is one reason that /proc suffered
atrophy in the system: nothing was really using it. One could debate at length
the relative merits of each, but the long-term viability of both in their respective
system I think shows more that the parts that people use are made to work,
with warts well known and tolerated, rather than any one form being purer than
the other.

Warner

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140804/224198f7/attachment.sig>

[TUHS] Unix taste (Re: terminal - just for fun)

[Andy Kosela]

On Mon, Aug 4, 2014 at 5:24 PM, A. P. Garcia <a.phillip.garcia at gmail.com> wrote:
>
> On Aug 4, 2014 3:22 PM, "Norman Wilson" <norman at oclsc.org> wrote:
>
> <snip>
>
>
>> 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).
> <snip>
>
> To digress from the main topic, I realize that's just one example, but
> here's a counterpoint to it:
>
> We in Solaris designed /proc as a tool for developers to build innovative
> solutions, not an end-user interface. The Linux community believes that 'cat
> /proc/self/maps' is the best user interface, while we believe that pmap(1)
> is right answer. The reason for this is that mdb(1), truss(1), dtrace(1M)
> and a host of other tools all make use of this same information. It would be
> a waste of time to take binary information in the kernel, convert it to
> text, and then have the userland components all write their own (error
> prone) parsing routines to convert this information back into a custom
> binary form. Plus, we can change the options and output format of pmap
> without breaking other applications that depend on the contents of /proc.
>
> [ https://blogs.oracle.com/eschrock/entry/the_power_of_proc]

Interestingly, we at FreeBSD got rid of /proc in favor of procstat(1)
and ptrace(2).  I am still not too sure if it was the Right Thing(r)
to do though.  The decision was more based on the premise that
procfs(4) was neglected in recent years than on anything else[0].

[0] http://freebsd.1045724.n5.nabble.com/Why-is-procfs-deprecated-in-favor-of-procstat-td4028960.html

[TUHS] Unix taste (Re: terminal - just for fun)

[A. P. Garcia]

On Aug 4, 2014 3:22 PM, "Norman Wilson" <norman at oclsc.org> wrote:

<snip>
> 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).
<snip>

To digress from the main topic, I realize that's just one example, but
here's a counterpoint to it:

We in Solaris designed /proc as a tool for developers to build innovative
solutions, not an end-user interface. The Linux community believes that
'cat /proc/self/maps' is the best user interface, while we believe that
pmap(1) is right answer. The reason for this is that mdb(1), truss(1),
dtrace(1M) and a host of other tools all make use of this same information.
It would be a waste of time to take binary information in the kernel,
convert it to text, and then have the userland components all write their
own (error prone) parsing routines to convert this information back into a
custom binary form. Plus, we can change the options and output format of
pmap without breaking other applications that depend on the contents of
/proc.

[ https://blogs.oracle.com/eschrock/entry/the_power_of_proc]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140804/54f140ed/attachment.html>

[TUHS] Unix taste (Re: terminal - just for fun)

[Norman Wilson]

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

[TUHS] Unix taste (Re: terminal - just for fun)

[A. P. Garcia]

On Aug 4, 2014 9:00 AM, "Tim Bradshaw" <tfb at tfeb.org> wrote:
>
> On 3 Aug 2014, at 12:49, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
>
> > Exactly. I've often wondered what the heck exactly it is that GNU
Emacs, GCC,
> > etc are all doing with those megabytes of code.
>
> That's the wrong question.  On my laptop right now Emacs seems to be
about 37M after running for a while but not weeks (total VM I think). The
mail client I am writing this with is 118M (and some helpers apparently
which might push it closer to 150).  The reminders application is 90.  The
application I'm using to get these numbers is using more memory than Emacs.
>
> Emacs was a very big application, once, but in terms of feature/byte it
is now an extremely svelte thing compared with the bloated horrors that we
use all the time.
>
> (Non-GUI emacs is 6).

that's it. I'm taking away all your pdps and vaxen. you don't deserve them
anymore.  ;-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140804/d1a738c3/attachment.html>

[TUHS] Unix taste (Re: terminal - just for fun)

[Tim Bradshaw]

On 3 Aug 2014, at 12:49, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:

> Exactly. I've often wondered what the heck exactly it is that GNU Emacs, GCC,
> etc are all doing with those megabytes of code.

That's the wrong question.  On my laptop right now Emacs seems to be about 37M after running for a while but not weeks (total VM I think). The mail client I am writing this with is 118M (and some helpers apparently which might push it closer to 150).  The reminders application is 90.  The application I'm using to get these numbers is using more memory than Emacs.

Emacs was a very big application, once, but in terms of feature/byte it is now an extremely svelte thing compared with the bloated horrors that we use all the time.

(Non-GUI emacs is 6).

[TUHS] Unix taste (Re: terminal - just for fun)

[Steve Nickolas]

On Mon, 4 Aug 2014, Dave Horsfall wrote:

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

Though surprisingly "md" and "rd" didn't come up with them, as later in 
MS-DOS.

-uso.

[TUHS] Unix taste (Re: terminal - just for fun)

[Dave Horsfall]

On Sun, 3 Aug 2014, Lyndon Nerenberg wrote:

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

At one time, it was fashionable in Australia to claim that #/@ were 
"traditional" in some sense (probably because the DEC assembler used them 
as sigils), and when a US visitor came out he announced that most US sites 
switched away from them, to the sound of dropping jaws.

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

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

-- Dave

[TUHS] Unix taste (Re: terminal - just for fun)

[Lyndon Nerenberg]

On Aug 3, 2014, at 7:54 PM, Norman Wilson <norman at oclsc.org> wrote:

> 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 #.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140803/db7c1676/attachment.sig>

[TUHS] Unix taste (Re: terminal - just for fun)

[Norman Wilson]

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

[TUHS] Unix taste (Re: terminal - just for fun)

[John Cowan]

Noel Chiappa scripsit:

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

No, they are simply costs.  Like all costs, the idea is not to eliminate
them tout court, but to decide whether they are worth paying for what
you get.  Poverty can have a very high marginal cost.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
"Hacking is the true football."  --F.W. Campbell (1863) in response to a
successful attempt to ban shin-kicking from soccer.  Today, it's biting.

[TUHS] Unix taste (Re: terminal - just for fun)

[Noel Chiappa]

    > 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

[TUHS] Unix taste (Re: terminal - just for fun)

[John Cowan]

Noel Chiappa scripsit:

> Exactly. I've often wondered what the heck exactly it is that GNU Emacs, GCC,
> etc are all doing with those megabytes of code. 

GCC is parameterized for a lot more variability than actually exists
nowadays.  As for Emacs, it's traditional to call it bloated because of
all the Elisp code it ships with, but (as esr says in the paper I cited)
that's like calling the shell bloated because there are a lot of shell
scripts out there.  It's a category mistake.

> 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.)

That's basically just the kind of peeving that objects to the use of
computers as calculators and spelling checkers.  "What will Kids Today do
when a calculator isn't available?"  Well, what will they do when there
isn't any ink to dip their goose quills in?  If you're not an angel,
there is no real advantage to learning to dance on the head of a pin.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
        You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
        You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
                Clear all so!  `Tis a Jute.... (Finnegans Wake 16.5)

[TUHS] Unix taste (Re: terminal - just for fun)

[Steve Nickolas]

On Sun, 3 Aug 2014, Noel Chiappa wrote:

>    > 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.)

GNU is, and always has been, a waste of space.  I use it, but I think 
BSD's lean and mean approach is superior.

> 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?)

EVERYTHING runs incredibly slow.  Gates' law - the apparent speed of 
software halves every 18 months. :P

> 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.)

QFT.

I actually do a lot of programming in an even tighter space: 64K Apple //e 
target.  Horrible machine for C, but it's a relatively simple machine to 
grok except for the disk controller =P

-uso.

[TUHS] Unix taste (Re: terminal - just for fun)

[Noel Chiappa]

    > 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

[TUHS] Unix taste (Re: terminal - just for fun)

[A. P. Garcia]

On Aug 2, 2014 7:48 PM, "Noel Chiappa" <jnc at mercury.lcs.mit.edu> wrote:

<snip>
> 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.

the spirit of emacs without the bloat :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140803/0b7b3198/attachment.html>

[TUHS] Unix taste (Re: terminal - just for fun)

[Noel Chiappa]

    > 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

[TUHS] Unix taste (Re: terminal - just for fun)

[A. P. Garcia]

On Aug 2, 2014 4:19 PM, "Noel Chiappa" <jnc at mercury.lcs.mit.edu> wrote:

<snip>
> 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

That word, effectively, is an important one. Being so small, I expected the
editor to lack a scripting language. I was pleasantly surprised that it
does have one, and that it's a c derivative rather than lisp, a fine
language but not my favorite one. "Extensible and modifiable" doesn't
always mean the same thing to everyone, and well, you're a kernel hacker.

I must try this...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140802/02c88dd4/attachment.html>

[TUHS] Unix taste (Re: terminal - just for fun)

[Noel Chiappa]

    > 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

[TUHS] Unix taste (Re: terminal - just for fun)

[Dave Horsfall]

On Sat, 2 Aug 2014, Steve Nickolas wrote:

> > EMACS - eight megs and constantly swapping :)
> 
> I like my own version: "Enough Memory? A Concept Strange!"

Or the one seen in either ;login: or AUUGN:

EMACS - Editor too large

-- Dave

[TUHS] Unix taste (Re: terminal - just for fun)

[Dave Horsfall]

On Sat, 2 Aug 2014, Doug McIlroy wrote:

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

Arrgghh!  Same on Mac and BSD systems.

> 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?

Closest I can think of is public key crypto, strong hashes, etc.  Easy to 
explain in general terms, difficult to implement correctly, and had a heck 
of an influence.

-- Dave

[TUHS] Unix taste (Re: terminal - just for fun)

[Ian King]

On Aug 2, 2014, at 9:47 AM, Noel Chiappa wrote:
>
> 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.
>

After writing my general exam in MS-Word,  I swore off it unless  
forced to use it (i.e. collaborative requirements).  When a stupid  
but ambitious application program thinks it's smarter than you are  
and tries to 'correct' your writing (I now call it 'autocorrupt'),  
it's time to change.  These days I write in EMACS and format with  
LaTeX, printing in PDF.  I can't imagine writing my dissertation with  
the turd called Word.

Unfortunately, I have to keep MS-Worst on the family computer,  
because the public schools require parents to purchase for-profit  
software to support our children's education.  (There are too many  
incompatibilities with Open Office et al. that trip up my less- 
computer-savvy family members for the open-source tools to be a  
useful alternative in an compulsory MS world.)  Fortunately, I get it  
for free through *my* school.

For programming, I used to use exclusively vi, but tried EMACS out of  
curiosity and found its UI to be a less constrained than vi's modal  
approach.  I use Gnu, FWIW.  -- Ian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140802/00b8cb79/attachment.html>

[TUHS] Unix taste (Re: terminal - just for fun)

[Benjamin Huntsman]

>> EMACS - eight megs and constantly swapping :)

>I like my own version: "Enough Memory? A Concept Strange!"

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

[TUHS] Unix taste (Re: terminal - just for fun)

[Noel Chiappa]

    > 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

[TUHS] Unix taste (Re: terminal - just for fun)

[John Cowan]

Steve Nickolas scripsit:

> (That said, I'm a heathen and use nano. Don't care for emacs and the
> only vi I can stand is Watcom's.)

I've used nano, and for that matter Windows Notepad, on occasion.
A proper carpenter knows the use of every tool.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
The peculiar excellence of comedy is its excellent fooling, and Aristophanes's
claim to immortality is based upon one title only: he was a master maker
of comedy, he could fool excellently.  Here Gilbert stands side by side
with him.  He, too, could write the most admirable nonsense.  There has
never been better fooling than his, and a comparison with him carries
nothing derogatory to the great Athenian. --Edith Hamilton, The Greek Way

[TUHS] Unix taste (Re: terminal - just for fun)

[Diomidis Spinellis]

On 02/08/2014 17:28, Doug McIlroy wrote:
> 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?

With modern facilities (hardware, libraries, distributed open source 
development) today's small-scale isn't the same as what it was.  If one 
considers the exuberant size compared to functionality of Node.js (11M 
binary), Emacs (10M), gdb (5.2M), mysql (3.1M), and vim (2.1M), here are 
some examples of smaller-scale programs that punch noticeably above 
their weight.

- git (1.4M) (as a distributed filesystem with rich metadata and 
versioning with configuration management thrown in as a bonus)
- tex (309K)
- curl (154K)
- sudo (121K)
- dot (7.7K plus 730K for its libraries)
- traceroute (53K)

Some libraries that deserve mentioning, when compared to libruby (2.3M), 
libxml2 (2.2M), and libpython2.6 (1.6M), are the following:

- libssl (431K)
- liblua (177K)
- C++ STL (816K for /usr/include/c++/4.8.2/bits/stl_*)

* Numbers are "ls -lh" output from a 2014.03 Amazon Linux AMI on which I 
had an open shell window.

I also think software package management systems are "small-scale", if 
one considers the functionality they offer through the thousands of 
packages they can install.

[TUHS] Unix taste (Re: terminal - just for fun)

[Larry McVoy]

On Sat, Aug 02, 2014 at 07:04:14PM +0300, Diomidis Spinellis wrote:
> - git (1.4M) (as a distributed filesystem with rich metadata and
> versioning with configuration management thrown in as a bonus)

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.

[TUHS] Unix taste (Re: terminal - just for fun)

[Steve Nickolas]

On Sat, 2 Aug 2014, Larry McVoy wrote:

> On Sat, Aug 02, 2014 at 10:28:59AM -0400, Doug McIlroy wrote:
>> A symptom of why I have always detested emacs and vi.
>
> EMACS - eight megs and constantly swapping :)

I like my own version: "Enough Memory? A Concept Strange!"

(That said, I'm a heathen and use nano. Don't care for emacs and the only 
vi I can stand is Watcom's.)

-uso.

[TUHS] Unix taste (Re: terminal - just for fun)

[Doug McIlroy]

> 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

[TUHS] Unix taste (Re: terminal - just for fun)

[Larry McVoy]

On Sat, Aug 02, 2014 at 10:28:59AM -0400, Doug McIlroy wrote:
> A symptom of why I have always detested emacs and vi. 

EMACS - eight megs and constantly swapping :)

I like vi, there is a learning curve but what is better?  I tried emacs, it
was too much for my feeble brain.  

I used to carry around a version of xvi (a variant that did buffers so you
could split the screen and see two different parts of a file or two different
files).  I had hacked that so it used \n as a terminator (I think I wacked
things so that \n or \0 were considered terminators) and made it use mmap
to look at the file.  This meant I could fit a ~3MB file in the editor on
a 4MB machine.  It was a pretty big win at the time.

Then we got more memory and then vim came along and I've never looked back.

So Doug, ed?  Or what?  I know some people are fantastic in ed, I used to 
be OK especially when I was going in through a serial port but I can't see
using that for serious programming these days.  Maybe I'm lame.
-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm