Skip to content
Tech News
← Back to articles

Project Xanadu: Even More Hindsight

read original more articles
Why This Matters

The retrospective on Project Xanadu highlights how technical limitations and lack of practical design hindered its potential, offering valuable lessons for current and future hypertext and software development efforts. Understanding these historical challenges underscores the importance of iterative design and real-world use cases in creating impactful technology.

Key Takeaways

Retrospective on Project Xanadu’s success and failure: a lack of design iteration, meaningful use-cases, or practicality stopped a valuable vision from maturing into something useful. (And contrasted with my approach.)

In December 2024 during a visit to San Francisco, I was lucky enough to be invited at the last minute to a party that could only have happened there: a celebration of the 50th anniversary of hypermedia visionary Ted Nelson’s manifesto, Computer Lib/Dream Machines, extolling the vision of Project Xanadu hypertext. I’ve contributed to English Wikipedia for 20 years now, and I’ve been working on Gwern.net on and off for 15 years now, so I could not possibly miss an entire party of people with strong opinions on hypertext.

Our host, James, had arranged for a surprisingly extensive collection of Nelson memorabilia: not just copies of that book (far larger and more impressive in person than I had realized, similar to a Compact OED in requiring a magnifying glass, also provided), or Nelson’s book The Future of Information, but also copies of his Swarthmore College mimeograph magazines, and most impressive of all—several vintage computers running copies of various Xanadu implementations.

Ted Nelson was still alive at age 87, but unfortunately could not attend. Fortunately, one of the attendees was one of the former Xanadu programmers from the Autodesk era (c. ), and we could listen to some of his stories.

They were a reminder of how, while we romanticize earlier eras of computing, the hardware constraints were really quite severe, and made productive development difficult. I think some disappointments in past software systems become more comprehensible when we remember how much time and ingenuity is spent working around the limitations—eg. McIlroy 1982 is justifiably proud of the months of clever algorithm design & optimization he did to get a useful spellchecker to fit in RAM in under 1MB that today we would write in a few lines of JavaScript (and done by an LLM).

For example, he described how they prototyped Xanadu in Smalltalk (which made sense, as a highly-productive, pleasant language/OS whose object-oriented model matches hypermedia beautifully), but then had to cross-compile it to C++ and compile that… which took about a week to compile. Not a minute, or an hour, or even a day, but a week. (And I thought that Gwern.net’s multi-hour compile-times were bad for my development speed!) He also had to waste a lot of time dealing with C++ silliness and compile issues.

Getting this to run at all for the PCs we saw was a challenge, and one reason for the party.

I had, I must admit, sometimes wondered how the Xanadu years at Autodesk could have so little to show for multiple fulltime man-years, when implementing the various client-side transclusion or popup features on Gwern.net were typically a few days of work for Said Achmiz. But hearing some war stories from the horse’s mouth helped put things in proper perspective, and remind me just how incredibly compute-impoverished people were at that time. (Perhaps worse than the CPU was the storage: I take for granted being able to host any PDF or PostScript or HTML file I need, but a meaningful fraction of my hosted documents exceed the total hard drive space of a mid-range PC, which might have a 50 MB hard drive. Meanwhile, the Markdown source files of the Gwern.net essays are themselves ~40MB, the annotations twice that, and the final site is 221,438 MB!)

The college magazines were a surprise and entertaining to leaf through: young Ted already liked to write, quite a lot, and dispense his advice. Someone mentioned that Nelson had dreamed of being a Hollywood director and regretted that he went into technology instead; I thought that made sense and explained some things about his auteur approach to software development (like his insistence he is “not a programmer”, 50 years later) or use of film-editing metaphors like “edit decision lists”.

I also had never sat down to read Computer Lib/Dream Machines properly, and leafed through a few pages. It was interesting to see such a large book, in multiple columns to get as much in as possible: Nelson can’t assume the reader knows anything about computers and has to start from scratch to explain the basic concepts like bytes or files. (You really would need the magnifying glass if you were older.)

... continue reading