Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!mgnetp!ihnp4!houxm!houxz!vax135!cornell!uw-beaver!tektronix!hplabs!sdcrdcf!sdcsvax!akgua!mcnc!decvax!cca!ima!haddock!dan
From: dan@haddock.UUCP
Newsgroups: net.unix
Subject: Re: Least We Forget:  MULTICS - (nf)
Message-ID: <208@haddock.UUCP>
Date: Tue, 10-Jul-84 23:44:47 EDT
Article-I.D.: haddock.208
Posted: Tue Jul 10 23:44:47 1984
Date-Received: Wed, 18-Jul-84 03:41:12 EDT
Lines: 54

#R:sri-arpa:-160800:haddock:16700026:000:2967
haddock!dan    Jul  9 20:09:00 1984

Multics was indeed responsible for many of UNIX's best features.
The innovation of UNIX was the notion of pipes, filters, and small
programs which could be quickly and easily coupled together to do
useful work.  Also, UNIX was once much simpler than Multics, but I
don't think it's true any longer; compare either System V.2 or
Berkeley 4.2BSD to Multics, and I think you'll find it's a tie.

The things that Multics has (present tense--you can still buy one,
you know) that I miss on UNIX are consistency and dynamic linking.  In more
detail:

* Consistency.	Multics has a set of closely followed guidelines for
writing commands, which means that command names, arguments, and error
messages are very consistent.  Command names and arguments have both long
descriptive names and short, easy-to-type names (e.g., create_dir and cd).
They are slightly more verbose than names and arguments in UNIX, but
they were much more consistent and much easier to remember as a result.

Error messages on Multics were always of the form
    progname: System error message.  Program-supplied error message.
The error messages were complete English sentences, which was good for the
novice, and programmers could easily replace them (see below).	(Messages
like "The specified control option is not implemented by this command." did
tend to get tiring after awhile on low-speed terminals, which is of course why
UNIX programs just say "bad flag".)

UNIX has gotten better about this one; pr doesn't say "very funny" anymore,
rmdir doesn't say "Values of B may be greater than dom!", and you're often
told the name of the program that's failing, too!  Now if only you could
learn the kernel error, too!  (USG, are you listening?)

* Dynamic linking (which would fit very smoothly into the UNIX framework,
and would have lots of advantages for program development), and extensive
use of "library" routines for common tasks that anyone could replace (via
dynamic linking).  One of the first things I did when I started using Multics
was to replace the error-message routine with one of my own that gave briefer
messages.  Someone else I know replaced the question-asking routine with one
that would take 'y' or 'n' in addition to the words 'yes' and 'no'.  As
with UNIX, while it wasn't perfect, you could easily fix it--usually more
easily than with UNIX, in fact.

Another application of dynamic linking was the I/O stream facility, which
(among other things) permitted you to insert modules between all programs
and your terminal.  If UNIX had this facility, there wouldn't be periodic
arguments about terminal paging--those who wanted it would just put it
in an I/O module to be inserted in your terminal output stream.  (One creative
person wrote a "German" I/O module--it would give everything written to your
terminal a German accent.)

To quote Sherlock Holmes, "I have written a small monograph on the subject"
of dynamic linking, and I'll send it to anyone who's interested.