Y Combinator's Xerox Alto: restoring the legendary 1970s GUI computer

Is it that the "small set of sharp tools" provided by C, and the "safe and somewhat onerous discipline" provided by Modula-3 represent two points on an evolution that's converging towards the ideal systems programming language? Or maybe the language level is the wrong level at which to be considering this, as if we were analyzing prose at the level of phonemes?

It seems crazy today but not in context. There wasn't video hardware in today's sense. There were either mainframes (with channel controllers) with the terminal doing the "rendering" or minicomputers and microcomputers in which the CPU did everything (which is what I guess it was like before the mainframe era).

You can see this reflected in Unix, and therefore in Linux: unix was developed for the PDP-7 (and later -11), a reimplementation of some of the ideas of Multics, which ran on a mainframe. So C's IO was "user mode" (I seem to remember a funny line in the original version, something like, "You mean you I have to call a function to do IO?") and the kernel had expensive, primitive IO capabilities and involved the CPU in everything. Well, there wasn't any alternative in the smaller PDP line (FWIW PDP-10 were larger machines than the -7 or -11, though only the later models had channel IO).

Memory mapped IO was not uncommon on minicomputers.

> I'm confused about your portrait vs landscape comments, though. The ADM-3A, Hazeltine 2000, VT-52, 3270, as well as Datapoint, Four Phase, Viatron, etc had a horizontal display, not a portrait display.

I'm confused / unclear. Those terminals had more columns than rows, true, but the character positions were rectangular. So the ADM-3 and the Datapoint were rather square, actually, because TV tubes were squarish, not paper-like as I claimed. I think I biased my memory because I used a bunch of hacked terminals like AAA Ambassadors which could cram 80x48 rather than 80x24 and because of the rectangular characters were portrait-ish. Unfortunately it's too late to go back and edit my comment.

Just look up the logic diagram in your copy of The TTL Data Book.

(I find the Nova instruction set strangely similar to the ARM in many ways, but maybe I've just spent too much time looking at the ARM1.)

http://www.monoprice.com/product?c_id=108&cp_id=10828&cs_id=...

As it was mostly used for DTP it made loads of sense.

In the end I missed the horizontal space often enough that I've now settled on having at least one full-size - i.e., not laptop display - landscape display in the setup. (Currently I've got my laptop, 1 x landscape in front of me, and 1 x portrait to the side.)

If you're going to do this, I guess you want to buy IPS-type monitors to minimize colour discrepancies due to the wide range of viewing angles you'll be using. eIPS is supposed to have a 170° viewing angle, but the colours on mine still aren't quite consistent from side to side (or top to bottom as it is once rotated). If you've got a TN-type display I imagine it will be even worse.

Also might be worth buying all your monitors at once. I bought mine over a couple of years; the colour temperature is very slightly different on each one, even when using the factory-calibrated settings, and one has a noticeably different anti-glare coating.

Edit: I've changed the link. Thanks for letting me know about the bad redirect, golergka. The jwz link looked fine to me; it's pretty obnoxious if the site does a NSFW redirect.

That's pretty simple to explain: all those other options were just way too slow to get the kind of performance required out of the hardware available at the time. The difference was simply too large to be ignored.

It's all nice and good to theorize about how the past should have been, but without UNIX you probably wouldn't be writing any of this on the medium you're currently using.

It has its flaws and it is far from perfect but at the time it fit the bill nicely.

The real problem is that we are categorically unable to move on when better options are around. There is a large amount of silliness involved when it comes to making responsible choices in computing, lots of ego, lots of NIH. Those are the real problems, not that UNIX was written in C.

I'm not sure it cost anyone anything. I mean, a lot of the OSes were/are written in it, so if you were going to go down that path you'd have to not totally forget to add a rather large benefit in the credit side. It's hard to imagine but programming wasn't always about compensating for not quite understanding how the 17 different frameworks you've downloaded from github and dragged into an IDE worked by just getting a faster machine. Once upon a time people had to carefully measure how much to unroll the loop, or how small a lookup table they could get away with before the errors become a problem.

The Alto was not meant to be a personal computer but a "personal supercomputer"—hardware so far ahead of the curve that it could run the software of the future. In other words, not a personal computer but a machine for inventing personal computing with, which of course they proceeded to do. Having such hardware is what makes it possible to figure out what the software of the future needs to be. If you can't run it, you can't create it.

For me this sheds light on a couple of Alan's famous lines: that the best way to predict the future is to invent it, and that people who are serious about software need also to be serious about hardware.

Such advanced hardware is necessarily costly but should still be within the reach of a properly funded research lab. It seems to have been an enormous frustration to Alan and his colleagues that they were unable to persude hardware vendors to make such hardware at any price, especially the Alto's microcode-driven style of hardware. Among other things, that was what had enabled the PARC researchers to make the most of the limited memory they had, since when a task was consuming too much memory they could implement it in microcode, pushing it down to the hardware (at least from the software's point of view) and freeing up RAM for software.

Interesting to note (as @pjmlp mentions) that 1973 + 15 years leaves us at around the time the Amiga 2000 was introduced. I remember ours (a model b IIRC) initially had a 20MB hard-drive, later upgraded with another 40MB for a total of 60MB of storage. It could fit almost all of my floppies on there!

Looking at the wikipedia page for the Amiga 500 I see the RAM latency listed as 150 ns. I'm not sure if that's the actual latency to read data from RAM - if so it's within an order of magnitude for accessing RAM today! (I'm also a little sad that while my i7 is a lot faster than that ageing 68000 that ran at 7.5 Mhz, it's still not easy to find a single core with 7.5+ Ghz of performance :-( ...).