[TUHS] Dennis' Draft of the Unix Timesharing System: not so draft?

Tim Bradshaw tfb at tfeb.org
Fri Dec 23 02:36:27 AEST 2016

> On 19 Dec 2016, at 20:10, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
> On a related note, great as my respect is for Ken and Doug for their work on
> early Unix (surely the system with the greatest bang/buck ratio ever), I have
> to disagree with them about Multics. In particular, if one is going to have a
> system as complex as modern Unices have become, one might as well get the
> power of Multics for it. Alas, we have the worst of both worlds - the size,
> _without_ the power.

This is slightly tangential, but I think it's fairly hard to take a simple system and turn it into a complicated system without ending up with a mess (and I claim that modern Unix is a mess).

I spent a bunch of my life programming in Common Lisp: CL was famously thought of in the about 1990 as an *extremely* large language with many baroque complexities: the standards document I think was over a thousand pages, even with lots of things you actually need missing, and there were features which people regarded as hard to implement efficiently without special hardware support (they were wrong, but it was a common thing for people to say at the time).

And whatever CL was it was not particularly pretty or elegant as a language, at least on the surface: the standards people valued agreement with each other and easy compatibility with older Lisps over elegance, so there were just lots of things which were there for no really good reason other than that they had been there in older Lisps.

(Of course 'extremely large & baroque language' means 'a tiny fraction the size of modern C++', but this was in the early 1990s before the true horror of C++ had become apparent.)

A lot of people were just derisive about CL: in particular the Scheme people.  Scheme was this tiny and *extremely* elegant language.  Programming in Scheme was just nice, because it was so small: R4RS seems to be 55 pages, including formal semantics and macros, I can't find R3RS in page-countable form, but it must have been 40 pages or something (no macros).  And tail-call elimination with first-class continuations: all the guilty pleasure of GO TO without the guilt.

Scheme was just great, except you couldn't do anything useful because it was so minimal.  But apart from that, great.

So now I use Racket which is a sort of Scheme which has eaten too much and read too many computer science text books.  And although it's just an enormously nice language, the moment you try to use some of its more industrial parts (structures or the object system) you realise *just how careful the design of those things in CL was*.  Nothing about the CL design was pretty, but it was designed by people who had both used the system themselves *and talked to many other users*, and addressed the things that made their lives hard.  So, of course, I still program in CL because, though it's ugly as shit, it's very very sorted out.

So, finally getting to the point: I think it's significantly hard, to take small elegant systems and turn them into large industrial systems: if you want large industrial, you need to design for large industrial and not worry too much about elegance.  Unix is kind of the poster child for what happens when you don't do that.


More information about the TUHS mailing list