🚀 go-pugleaf

    >Well, I beg to differ. Compared to things like VMS, System V, BSD Unix,
    >etc..., Multics was remarkably small, simple, and fast. 
    
    Huh?  Multics is/was *huge* (all those lines of PL/I add up, you know
    8-))!.
Message-ID: <1549@aber-cs.UUCP>
Date: 21 Dec 89 18:11:19 GMT
Reply-To: pcg@cs.aber.ac.uk (Piercarlo Grandi)
Organization: Dept of CS, UCW Aberystwyth
	(Disclaimer: my statements are purely personal)
Lines: 61

PL/1, if used carefully, is not that horrible at all, and the Multics guys
had an *excellent* compiler. I read an old MIT TR in which (Saltzer?) there
was a discussion of truly kernelizing Multics, and line counts for the
various system modules were given, and it was not *big*. Notice also that the
linker in Multics is considered a part of the system.

Remember that Unix V7 was about 10-20,000 lines, and that current BSD or AT&T
Unixes run well into the hundred thousands. I would really like to see a
line count, side by side, of SunOS 3 or 4, and System V.3 or 4, and of
Multics. It could be surprising... I doubt *I* would be suprised.

    The "kernel" was, I suppose, smaller than you would expect,
    but Mach is tiny comparatively (for the same reasons...).

After all Multics used a few elegant concepts thoughtout, and this leads to
simplification in a lot of places, and the standard use of shared libraries
meant a lot of code reuse, which the Multics guys were very keen about.

I also doubt that non kernel parts of Multics are longer than for other
systems. Most of Multics was done by very careful programmers operating under
a well understood set of principles, conventions, ideas, quite unlike Unix.
And again, having high quality shared libraries means *a lot*. I would gladly
throw away many of the Unix tools I have for the equivalent ones under
Multics, which are smaller and more sophisticated. For example, GNU Emacs vs.
Multics EMACS, rn vs. confer, RDMS vs. most every other DB, etc...

I may again be wrong, but I think that the perception of Multics as huge is
really psychological, because the typical Multics kit was huge indeed; I
worked on a many (12, if I remember correctly) processor H6080, for one.
    
    GNU Emacs is a poorly-written program.

Especially as to memory management (editing with the gap method, no
ccompaction of the lisp workspace, ...).

    There *was* a version of emacs that ran under Multics, and even had a
    LISP-interpreter, I believe.

On the other hand the Multics EMACS, which I had the pleasure to use, by
Greenberg, was *written* in Multics Lisp, which I had the pleasure to use
too. Great thing. Almost conceivable only under Multics. At times I used
Multics Lisp as my shell, an idea that under Unix was done by sombody at Yale.

Once you understand that pipes are bogus and you could say "(sort (ls))"
instead of "ls | sort", something that is only really practical with one
level shared memory architectures, you don't want to go back again. I don't
know it it has been ported, but I think that Icon would also make a fine
Multics shell. Not that the native shell was bad, mind you...

I am sorry about RMS' feelings :-), but I came to believe that Multics EMACS
was *the* proper EMACS, and the original Teco EMACS and the various C
EMACSes floating around just not up to par.

Now RMS or somebody of that ilk could well observe that the model EMACS
should be LMI ZMACS, and I may agree, except that it was overdone and
hackerish. On the other hand interactive programs are really best done in
an interactive language, or at least in a dynamic binding environment.
-- 
Piercarlo "Peter" Grandi           | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk