[comp.misc] Editor Wars

jeffd@ficc.uu.net (jeff daiell) (03/18/89)

Perhaps the ultimate solution is one suggested in comp.society.
futures:  computers that respond to telepathic commands!  No
more scripts, no more macros, not more aliases, no more
function keys.....

"'Tis a consummation devoutly to be wished."

                       - W. Shakespeare




Para un Tejas Libre,

Jeff Daiell
(opinions my own, until taxed away)



-- 
"Buy land.  They've stopped making it."

                 -- Mark Twain

pavel@dgp.toronto.edu (Pavel Rozalski) (03/19/89)

I have a modest proposal to make (with apologies to J. Swift).

     Periodically, the eternal debate over which editor to use crops
up. The emacs-style editor users expound on the functionality and
expandability of their editors. The vi users like ease of use and
widespread availability of vi. The ed group mumble something rude
about real men (er, programmers) don't use visual editors and
everything useful can be accomplished with ed. These are the initial
arguments used. Soon after a religious battle ensues with each faction
calling other factions rude names. The debate has been known to end up
with a brawl of computer types kicking and screaming, trying to
physically prove that one editor is better than the next.

     I would like to propose a simple solution to end these feuds. I
suggest that we enter all our files with:
cat >foo

The advantages are numerous. 

Everything that one would wish accomplish can be done with this. Any
file or program can be easily entered. There is an added onerous of
getting the text or program right on the first try. Users would
ponder more on the meaning and correctness of each line before
foolishly typing return. The decision of whether to modify (that is
rewrite and clobber) an old file would also be taken with more
gravity.

When editing programs, programmers would find it useful to split a
larger program into many smaller source files, perhaps with one
function or procedure per file. This would lead to very modular code.

New users would have very easy time adapting to the commands - there
really are none. There is the delete key and return key which most
users are quite used to. The only extra function is the
exit-editor-and-save-file command which is almost always defined to be
Control-D. No heavy concepts such as backup files, cursor movement
(let alone page up or page down!), editing multiple files, many
confusing modes, regular expression matching, macro definitions, etc.
Simple.

cat is, as far as I know, guaranteed to run identically on all UN*X
systems, and then probably some which do not even run UN*X (there are
probably functional equivalents in most OS's). There would be no need
to port it to every new UN*X system as it would probably already be
installed.


cat is not a strain on system resources. It does not eat up much CPU.
Upon examining some files on our system (Sun 3's, running SunOS 3.5) I
found the following:

-rwxr-xr-x  1 root        24576 Nov 10  1987 /bin/e
-rwxr-xr-x  1 root        24576 Nov 18  1987 /bin/ed
-rwxr-xr-x  1 root        32768 Sep  4 23:53 /usr/local/ed
-rwxr-xr-t  1 root       131072 Nov 18  1987 /usr/ucb/vi
-rwxr-xr-x  1 root       204800 Oct 17 20:58 /usr/local/jove
-rwxr-xr-x  1 root       868352 Sep  5 18:38 /usr/local/emacs

And of course:
-rwxr-xr-x  1 root        18644 Nov 10  1987 /bin/cat

This program takes up very little disk space. It has no support files
or programs. I suspect there is a version in the public domain.  It
would probably be never swapped out. cat could probably be further
hacked to optimize for editing speed and reduce the size by taking
out all those undesirable features added to cat since UN*X left Bell
Labs.


So I make this proposal to competent system administrators everywhere:

Remove all those other editors. Try cat for a while. I firmly believe
it will make your system a more memorable one.

Pavel Rozalski

CSNET:	pavel@dgp.toronto.edu   CDNNET: <...>.toronto.cdn
UUCP:	{decvax,linus,utzoo,uw-beaver}!utcsri!dgp!pavel
ARPA:	pavel@dgp.toronto.edu
BITNET:	pavel@dgp.utoronto (may not work from all sites)