Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!quick!srg
From: srg@quick.COM (Spencer Garrett)
Newsgroups: comp.arch
Subject: Small is beautiful
Message-ID: <121@quick.COM>
Date: Sun, 20-Sep-87 23:09:42 EDT
Article-I.D.: quick.121
Posted: Sun Sep 20 23:09:42 1987
Date-Received: Mon, 21-Sep-87 04:22:50 EDT
Organization: Quicksilver Engineering, Seattle
Lines: 46

I'd like to start by saying that I'm firmly in Henry Spencer's camp on this
one.  Performance isn't the only benefit, however.  Smaller programs are
easier to write, debug, maintain, and (drumroll here) *use*.  I measure
"small" by economy of concepts more than line or byte counts, though they
tend to follow.  Let me give an example.  For many years (back in the dark
ages) I used TECO as my primary text editor.  I used it day in and day out,
and I consider myself a wizard (I wrote a multi-user, protected mode OS
for the PDP-8 during this time!), but I *never* reached the point where I
didn't want the TECO manual handy at all times.  Later I found myself in
charge of a system with a screen-oriented editor very reminiscent of TECO
(you know - every ascii code is a command, and then some).  These editors
are very powerful, (I've seen a screen editor written as a TECO macro, for
pete's sake!) but they are complicated to use and impossible to remember.
Well, *everyone* waited to use the screen editor rather than using the line
editor, but it only ran on an expensive vector display which we couldn't
afford to replicate.  I spent quite a while watching how people used it
before starting to write a screen editor which would run on ordinary terminals
(this was pre-UNIX and very pre-VI).  I discovered that half a dozen commands
constituted nearly the entire working set for most users.  Most of the time
they would hold the right arrow key down and let it auto-repeat to get to
the end of the line, rather than trying to remember the direct sequence.  I
decided that what people needed was an editor simple enough to use that it
wouldn't get in their way, so they could think about the program and not
about the editor.  Well, I wrote it and it has many rabid adherents to this
day.  It has grown to a whopping 2800 lines of C, and nobody bothers to keep
the manual handy.  It takes about 32k + buffer(expanding) and averages
1/6th the cpu of vi.  It has maybe 20% of the functionality of vi, but that's
more than almost anybody can remember how to use in vi.  The source code for
vi, on the other hand, is twice as big as the V7 kernel, and there are well-
known bugs that nobody can find.  On the other end of the scale, I've seen
a single copy of EMACS bring a 750 to its knees, and you have to think very
carefully about every keystroke or you may delete every source file in the
county.  The difference here is one of design, not implementation.  I couldn't
write vi in 2800 lines, much less EMACS.  I simply chose to seek the essence
of editing, not the outer limits.  It was exactly this feeling which gave us
UNIX instead of VMS, and I don't think the shrinking cost of mips and megabytes
is any reason to abandon the quest.  I therefore humbly proclaim Spencer's Law:

	No program over 10,000 lines long can ever be made to work (correctly).

I think this fundamental constant describes people, not computers, but that
is, after all, what this business is really about.

I hereby don my asbestos suit and set my autodialer to 911 ---

					spencer