[TUHS] Hypothetical: Could MULTICS have been written in C, if available?
Tom Lyon via TUHS
tuhs at tuhs.org
Tue May 26 10:40:34 AEST 2026
IBM's TSO (on OS/MVT and MVS) was awful ("like kicking a dead whale down
the beach" - scj) but it worked - I used it for 3 summers. Princeton tried
hard to get TSS/67 working (before my time) but gave up. VM/370, otoh, was
a fine system that IBM tried to kill several times because it came from the
skunkworks, not the giant software organization. Shoutout to both Varians
for their fine work.
TSS development was killed and revived a couple of times. The only serious
user I ever heard of was Bell Labs, (10+ years after initial promises) and
they did their port of UNIX to it.
On Mon, May 25, 2026 at 5:24 PM Clem Cole via TUHS <tuhs at tuhs.org> wrote:
> below
>
> On Sun, May 24, 2026 at 11:14 PM Adam Thornton via TUHS <tuhs at tuhs.org>
> wrote:
>
> > That tracks: Melinda's husband Lee is the only person I know who really
> > used TSS.
> >
> You might be surprised. A number of us used TSS and MTS extensively before
> we saw UNIX, and they influenced many things. For instance, Ted Kowaski
> and Bill Joy were MTS hackers before they saw UNIX. I had been working on
> TSS [supporting York/APL at the time]. Ted and I had both used tools like
> IBM's disk scavenger tools. The creation of fsck(8) was a direct result of
> that [it was also why the error messages were all UPPER CASE - that was how
> we had been taught earlier]. I'll let Tom Lyon speak for himself, but he
> also had extensive mainframe experience, and I expect it influenced his
> thinking later on.
>
> The point is that what we think of as Unix is clearly unique. But, as
> with most man-made things, standing on the shoulders of others was not
> unheard of, and influences from previous and current systems certainly
> guided many of the choices made by different UNIX developers. [Of course,
> Hamming is said to have quipped: *"Mathematicians stand on each other's
> shoulders while computer scientists stand on each other's toes." ].*
>
> Coming back to the question of PL/1 *vs. *C, I have a longer responce on
> quora: https://www.quora.com/What-makes-the-C-language-powerful that I
> will crib here. When PL/1 and Algol68 were being created, and frankly,
> later with Ada and others, there was always a tendency to go overboard.
> But to me, the less-is-more rule applies: C is powerful not only because of
> what is in the language but also because of what Dennis (and Ken) left out.
> C was not trying to be all things. But it does mean that part of the power
> of
> C is that it is the programmer's responsibility to write appropriate code.
> The
> C programming language was a tool they needed and would work well for them.
> Its staying power has been because it was so good at what it did. As Doug
> pointed out, IBM had envisioned PL/1 as its grand solution. Both
> Scientific folks and Commericial folks had one tool. Remember what wisdom
> Dennis once offered: *"When I read commentary about suggestions for where C
> should go, I often think back and give thanks that it wasn't developed
> under the advice of a worldwide crowd."*
>
> The fact is, B lived a long time on the GE/Honeywell systems, even with
> alternatives such as PL/1. The 36-bit nature of the GE hardware was less
> natural for C, but I suspect common solutions to some of the problems would
> have become mainstream if the 36-bit world had lived longer at either
> Honeywell or DEC. Although I thank Fred Brooks, who was right in about 1963
> when he tossed Gene Amdahl out of his office and told him he did not care
> if Gene thought it was a waste of hardware. *"Any size that was not a
> power of two was too difficult to program,"* and he should *"not come back
> until bytes and words are powers of two".*
>
More information about the TUHS
mailing list