The future still isn't what it used to be: Vannevar Bush

(According to Blogger, this is the 700th post on this blog, which seems like a completely arbitrary milestone to note, but I noticed it nonetheless, so now you get to. You're welcome.)

Vannevar Bush casts something of a long shadow. He held several high-level technology-related posts in the FDR and Truman administrations, had a long and distinguished academic career at MIT and elsewhere, and won several prestigious awards, including the National Medal of Science. His students included Claude Shannon, whose work in information theory is still directly relevant, and Frederick Terman, who was influential in the development of what we now call Silicon Valley (I used to work fairly near Terman Drive in Palo Alto).

Bush is also often credited with anticipating the World-Wide Web in his Atlantic Monthly article As We May Think. Since I've been comparing early visions of the Web with what actually happened, I thought I'd take a look. I've linked to the ACM version rather than the Atlantic's version, which may or may not even be online, since the ACM version highlights the relevant passages. Though there's a Wikipedia page on the piece, I've deliberately skipped it in favor of Bush's original text (with the ACM's highlights).

Two things jump out immediately, neither directly relevant to the web:

• The language is relentlessly gendered. Men do science. Girls [sic] sit in front of keyboards typing in data for men of science to use in their work. A mathematician is a particular kind of man, technology has improved man's life, and so forth. Yes, this is 1945, and we expect a certain amount of this, but from what I can tell Bush's style stands out even for the time. I mention this mainly as a heads-up for anyone who wants to go back and read the original piece -- which I do nonetheless recommend.
• There is an awful lot of technical detail about technologies that would be obsolete within a couple of decades, and in several cases nearly fossilized by the dawn of the Internet in the 1970s. Bush speculates in detail about microphotography, facsimile machines, punch cards, analog computers, vacuum tubes, photocells and on and on for pages. Yes, all of these still existed in the 1970s (I spent many an hour browsing old newspapers and magazines on microfilm as a kid), but digital technology would make most if not all of them irrelevant before much longer. As far as predicting the technology underpinning the web, Bush's record is nearly perfect: If he speculated about it, it almost certainly isn't relevant to today's web.

Two thoughts on this. First, it's almost impossible to speculate about the future without mentioning at least something that will be hopelessly out of date by the time that future arrives. In our own time, all we have are the tools and mental models of the world of that time. I don't fault Bush for thinking about the future in terms of photographic storage, and I don't this takes anything away from his thoughts on the "Memex", which is what people are referring to when they talk about Bush anticipating the web.

I just wish he hadn't done nearly so much of it. Alan Turing's Computing Machinery and Intelligence spends two sentences on the idea of using a teleprinter so that it's not obvious whether there's a human or machine on the other end of the conversation, and one of those sentences just says that this is only one possible approach. That seems about right for that paper. In Bush's case, I could see a few paragraphs about how to store large amounts of information (for those days, at least) on film or magnetic media, and so forth. The article would have been much shorter, but no less interesting.

Second it's worth noting how many things were possible with mid 1900s technology. You could convert, both ways, between sound, image and video (in the sense of moving images) on the one hand and electrical signals on the other. You could store electrical signals magnetically. You could communicate them over a distance. You could store digital information in a variety of forms, including the famous punched cards, but also magnetically.

There were ways to produce synthesized speech and read printed text. Selecting machines could do boolean queries on data (Bush gives the example of "all employees who live in Trenton and know Spanish"). Telephone switching networks could connect any of millions of phones to any other in about the time it took to dial (and less time than it sometimes takes my phone to set up a call using my WiFi). Logic gates existed. For that matter, the first general-purpose digital computer, the ENIAC, existed in 1945 and Bush would certainly have known about its development.

In other words, even in 1945, Bush isn't drawing on a blank canvas. He's trying to pull existing pieces of technology together in a new way in order to deal with what was, even at the time, an overwhelming surplus of information. The gist of the argument is "If we make these existing technologies smaller, faster and cheaper, and put them together in this particular way, we can make it easier to deal with all this information."

The particular problem Bush is really interested in isn't so much storing information as retrieving it ("selecting" as Bush says). This is totally understandable for a national science adviser who had until recently been working on one of the largest technological efforts to date (the Manhattan Project). Bush cites Gregor Mendel's work having been essentially unknown until decades after the fact as just one example of a significant advance nearly being lost because no one knew about it, even though it was there to be found. Bush's desire to prevent this sort of thing in the future is palpable.

Bush mentions traditional indexing systems that can find items by successively narrowing down the search space (everything starting with 'F', everything within that with second letter 'i' ... ah, here it is, Field Notes on the Web), but he's much more interested in following a trail of connections from one document to another. That is, he's envisioning a vast collection of documents traversable by following links between them. That's the world-wide web. Ok, we're done.

Except ...

Bush sees the Memex as literally a piece of furniture, looking pretty much like a desk but with a keyboard attached along with various projection screens and a few other attachments. Inside it is a store of microfilmed documents together with some writable film, which takes up a small portion of the space under the desk, and a whole bunch of machinery to be named later, taking up most of the space.

Associated with each document is a writable area containing some number of code spaces, each of which can hold the index code of a document. There's also a top-level code book to get you started, and when you add a new document, you add it to the code book. To be honest, this seems a bit tedious.

To link two documents together, you pull them both up, one on one projection screen and the other on the other, and press a button. This writes the index code for each document in the other's next open code space. The next time you pull up either of the documents, you can select a code space and pull up the document with that code.

Codes are meant to have two parts: a human-readable text code and a "positional" numeric code (probably binary or maybe decimal). Linking this post to Bush's article might add "Bush-as-we-may-think" to a code space for this post, along with (somewhere offscreen) the numeric index for Bush's article, and "Field-notes-future-ramblings-Bush" to a code space on Bush's article (along with the numeric code for this post). At that point you've got one link in a presumably much larger web.  Actually, you have two links, or one-bidirectional link if you prefer. Not quite Xanadu's transclusion, but arguably closer than what we actually have.

Pretty webby, except ... coupla things ...

For one thing, this is all happening on my Memex. My copy of this post is linked with my copy of Bush's article. Yours remains untouched. If there's a way of copying either content or links from one Memex to another, I didn't catch it. Bush's description of how document linking works is hand-wavy enough that it wouldn't be particularly more hand-wavy to talk about a syncing mechanism (and/or an update mechanism), but I doubt Bush was thinking in that direction.

Bush seems to be thinking more about a memory aid for an individual person (or possibly a household or small office/laboratory). Functionally, it's a personal library with much larger capacity and the ability to leave trails among documents. It's certainly an interesting idea, but it misses the "world-wide" part. When I link to the ACM's version of Bush's paper, the link is from my blog to the ACM's site. If you write something and link it to Bush's paper, we're pointing at the same thing, not separate copies of it, and we're pointing to a thing that might be stored anywhere in the world (and someplace else next time we access it).

In the same post I mentioned above, I talk about a couple of features that make the web the web, particularly that a link can be dangling -- pointing to nothing -- and it can become broken -- you pointed at a page, but that page is no longer there (early posts on this blog are full of these, though at the time it wasn't clear whether rotting links would be an issue as storage got cheaper; they are). There's also some ambiguity as to what exactly a link is pointing to. If I point to the front page of a news site, for example, the contents on the other end of that link will probably be different tomorrow. In other cases, it's worth going to some effort to ensure the contents don't change significantly.

These may seem like bugs at first glance, but for the most part, they're features, because the flexibility they provide allows the web to be decoupled. I can do what I like with my site without caring or even knowing what links to it. Since a Memex is a closed system, none of this really applies. On the one hand, it's not a problem, but on the other hand, it's not a problem because a Memex is not a distributed system, which the web as we know it very much is.

Finally, the mechanism of linking is noticeably different from what HTML does. You have a pair of links between documents (or maybe pages within documents, given that that's what's on the screen when you press the "link" button?). An HTML link is between a particular piece of the source document to, in the general case, a particular anchor on the destination document. To be fair, this doesn't seem like an essential difference. You could imagine a Memex with a linking mechanism that goes from a piece of one document to a piece of another, which would be much more like an HTML link (and, arguably, more like a Xanadu transclusion).

[Really, though, an HTML link points to whatever the server on the other end serves up in response to that particular URL. The resulting page is often, one way or another, maintaining live connections to any number of other servers and updating its appearance accordingly. In writing the post, I implicitly assumed that everything was static text, since that was the world Bush was dealing in. The dynamic nature of real web resources is a whole separate dimension. The point here is that even without that Memex isn't really the Web -- D.H. April 2025]

So did Vannevar Bush anticipate the web by nearly half a century?

I think the fair answer is "not really", because the distributed, dynamic nature of the web is critical.

Did he anticipate the idea of an interconnected web of documents? I think the fair answer is "sorta". Again, actual web links are one-directional and non-intrusive. You can link from document A to document B without doing anything at all to document B or its associated metadata. You don't need a backlink and you generally won't have one.

This one-way form of link was not a new idea. Documents have been referencing each other forever. Bush's notion of linking is different from an HTML link, and since an HTML link is structurally the same as a reference in a footnote in a book, it's different from that as well.

In other words, the original idea in Bush's work is more an evolutionary dead end than an innovation. A pretty interesting dead end, but a dead end just the same.

Postscript:

There's one more thing that I'd been meaning to mention but, embarrassingly enough, forgot to: search. Bush is quite right in saying that people access information by content, but in the Memex world everything eventually boils down to an index number. You access document 12345, not "any documents mentioning Memex" or whatever.

Search is probably the aspect of the web with the least precedent in mid-1900s technology. There were ways to attach index numbers to things, or even content tags, and retrieve them, with a minimum of human intervention. Bush goes into those at length. But if you wanted to get to something by what was in it, you needed a person for that, if only to add indexing information. Indeed, Memex is aimed directly at making it easier for a human to do that task, by making it easy to leave a trail of breadcrumbs a human could easily follow.

It would be almost a half-century before documents could be easily accessed by way of what was in them.

Oh, and also ... in Bush's vision, linking documents together would be a frequent activity for anyone using a Memex. In today's web, not so much, except, I think, in the particular case of re-whatevering a piece of social media content. I think the reason for that is also search (see this early post for a take on that).

The disappearing (and reappearing) profile photo

Recently I noticed that my profile photo was broken (I've since fixed it).  "That's odd", I thought, "I uploaded it quite a while ago.  Maybe there's some glitch in Blogger's servers."  I kept checking, figuring it should come back before too long, but it didn't.  So I went to my Blogger profile to see what had happened to the image, and discovered that the URL I had given was broken.

I don't remember why I'd given a URL instead of just uploading an image.  Maybe I didn't have a copy of the image handy.  Maybe I just thought it was "webbier" to give a URL, but never mind.  Easily fixed.  I hunted up another copy of the image and uploaded it ... and we're back!

What's interesting, though, was that the URL pointed at Technorati, whose probably-no-more-tangled-than-usual history I've touched on before.  So I checked.  Technorati is still a thing, albeit clearly not one I personally pay much attention to.  Evidently they've redone their infrastructure a bit, or perhaps just cleaned out inactive accounts, causing the link to finally rot after however many years it's been since I first put it on my profile.

Links rot.  That's just part of the web.  In fact, it's a key architectural decision behind the web (as opposed to, say, Xanadu).  It would be interesting, though, to study which links rot, and when, and why.

In the case of my profile photo, a link to an obscure corner of Technorati, linked to a completely inactive account associated with a little-read blog, remained stable for years until, one day, it disappeared.  This is probably not too uncommon, but nonetheless I'd expect link rot to become less common over time.

In the old days, people would put up web sites on their personal computers, or on the workstation in their lab, and so forth.  They would get tired of the hassle of hosting the site, or graduate, or whatever, and the site would go away.  That's largely been replaced by web hosting services, but even then sites go away all the time as people get tired of paying for them and maintaining them.

However, a larger and larger portion of content is now being hosted by companies like Facebook, YouTube, Google, Twitter and so forth, or by major media outlets, which at least implicitly promise to maintain the content in perpetuity.  "Perpetuity" is rather better defined in theory than in practice, but I have a high degree of confidence that links to this blog will still work ten years from now, probably twenty and quite possibly fifty.

Will someone living a thousand years from now be able to read Field Notes?  I have no idea.  The odds of Google (or any of the other present-day giants) still being around in a thousand years are fairly small, but the likelihood of it costing peanuts to maintain everything that's ever been published on Blogger are pretty good, so who knows?

What does seem likely is that the bulk of "user-created content" will remain accessible as long as there is a web more or less like the present one for it to be part of.  If that's right, then the main sources of link rot will probably be companies folding and taking their sites down, or content owners deciding to take older content down or hide it behind paywalls or similar actions.  In other words, links are probably less likely to rot due to inattention or Life Happening to the particular person who created them in the first place, and more likely to happen due to explicit decisions by corporate entities.

Xanadu vs. the web: Part II - Xanadu the architecture

OK, so what is this Xanadu project?  First, if you want to explore for yourself, the project is at http://xanadu.net/.  Many of the ideas behind the project are expressed its founder Ted Nelson's Computer Lib, of which I have only read small excerpts.  My source for the history of the project is Gary Wolf's Wired article The Curse of Xanadu.  As the title suggests, the article does not paint a rosy picture, and Nelson has objected strenuously to it in the letters column of Wired itself.

Over its lifetime Xanadu has been a lot of things to a lot of people, but I'll focus on two aspects here:  Xanadu as an architecture (in this post) and Xanadu as a business model (in the next), before going on to try to make some sort of overall sense of everything.  Along the way I'll also touch on Xanadu as a software engineering project (or not).


So ... those first two paragraphs don't really belong in this post.  They belong in the previous one.  Now, I could go back and quietly edit Part I to include them.  I explicitly asserted the right to make quiet editorial changes quite a while back when trying to deal with a mistake I'd made.  But the upshot of that experience was that it's generally better to leave anything more than minor mistakes uncorrected and supply further material on the subject if needed (this theme will recur in a moment).  The principle I settled on was: a blog is not a wiki.  In particular, it has no visible edit history, so the blog itself must fill that role.

That's actually not a digression.  Any hypertext system has to deal with exactly the questions my little editorial decision raises, particularly: How do you handle a dynamically changing interlinked set of documents?  If I edit something that someone has a link to, what should they see?

In a blog (or at least in Blogger blogs), a link to a post is a link to the latest revision.  Exactly what you see may depend on when you chase the link.  With a wiki you also have the option of linking to a particular version of an article, which will never change, however many later edits may come along.  The W3C standards for HTTP and company recommend that links be to immutable data, but they do not require it.  The basic machinery of the web works the same either way.  Having results change over time is tolerated.

Xanadu takes a different approach to this and other issues.  In Xanadu, every object has a unique, secure identity.  This doesn't preclude keeping multiple copies for the usual reasons of performance and reliability, but these physical copies share the same identity and so represent a single logical object.  Objects in Xanadu are immutable.  If I revise a post, the revised post is a separate object from the original, which still remains.

Objects are addressable via lists of numbers called tumblers.  Tumblers are ordered, and given a tumbler it is always possible to find a tumbler after it but before any other existing tumbler.  This makes it easy to add new revisions.  Since tumblers are hierarchic by nature, it is possible to address parts within objects -- to address, say, the third paragraph of an article or a sentence in that paragraph, or a word in that sentence.

Links between objects are two-way, and they are visible objects in their own right.  Links are non-intrusive, meaning that you can add a new link to or from an object without changing that object.  The endpoints of a link are just tumblers [if I've got it right].  Since tumblers can address arbitrary parts of an object, you can define, say, a link from the word "Xanadu" in some article to the Wikipedia article on Xanadu without changing either the source article or the Wikipedia article.

Since the system retains every version of every object, and links are addresses pointing to (or into) existing objects, links are never broken (the referent is no longer there) or dangling (the referent was never created at all).

Xanadu takes this one step further by positing that all edits point back to an immutable record of the unedited original.  For example, if I boldface a word in a text, the boldfacing is separate from the original text.  Documents become collections of editing commands, which may reference other such collections, and so forth.

Finally (for the purposes of this discussion at least), Xanadu includes a notion of transclusion.  Nelson defines transclusion as "the same content knowably in more than one place".  Transclusion isn't the same as quoting.  I just quoted Nelson, but there's no way to navigate from that quote to its source.  Even if I make the quote a link, as "the same content knowably in more than one place", that's still not transclusion, first because the link points to the whole document, not the quote, but more importantly because there's no way to navigate back, or to other uses of that quote.  [From illustrations of transclusion, it's easy to interpret it as "showing quoted text inline", but that's a matter of presentation.  Whether the front end chooses to show a link or the full quoted text is its business.  It's the navigability that matters from an architectural point of view, because that two-way navigability requires cooperation with the outside world.]

This ability to slide back and forth between (or among) different uses of the same text is fundamental to Xanadu.  Other features, such as immutability and tumbler addressing, exist to enable it.

This architecture has several key differences from The Web as We Know It:

• Links in Xanadu are never broken.  Web links are routinely broken.
• Both endpoints of a link are fixed.  If I edit a post, I've constructed a new collection of edits pointing into the original post.  Your link points to the original, unchanged post.  In the web, there is only one object, which has changed out from under a link.
• Links in Xanadu are bidirectional.  If you link to my post, I (or you, or anyone else) can follow that link back to whatever you linked from.  I can easily and automatically navigate from a post to the comments on the post.  If you've commented on a particular sentence, I can see that because my end of the link refers to the sentence specifically.
• Links in Xanadu never go away, because nothing ever goes away.
• Markup lives outside a document.  If I want to boldface every example of the word "orange" in a document and you want to boldface every example of the word "banana", we can do this independently and without editing the original.
• Xanadu doesn't exist.  The web does.

That last may come across as snide, but unfortunately it's true.  Xanadu as a concept has been around in one form or another since the 1960s -- coming up on half a century.  In all that time, there has not been one commercial implementation of anything more than superficially like it.  Not from Nelson, not from the dozens of programmers who have worked with Nelson, not from anyone inspired by Nelson to make it a reality, not by someone working in isolation and coming up with the same approach independently.  This wants explanation.

From a technical point of view, it's tempting to look for scalability issues and other architectural weaknesses.  For example

• If I decide, say, to link every word of every Field Notes post to its dictionary definition (applying some hack for words already occurring in links), that's my business.  In Xanadu, the dictionary, at least, has to know about thousands of new links [More precisely, if not the dictionary, then whatever's keeping track of the links, and anything accessing the dictionary needs access to them.]
• Since Xanadu is meant to use redundant copies for performance and fault-tolerance, the keepers of every copy will have to know (or be able to find out about) all those links as well.
• And it all has to be kept in sync as changes come along.  Cache coherence is one of the hard problems, though it certainly helps that objects are immutable and the set of objects only grows.  Web protocols allow for caching, but stale cache entries can and do happen.  This is just a fact of web.life, and web.life goes on.
• Suppose I really did want to link to the latest revision of something, whatever that may be at the moment.  If you edit that something, then the link needs to be updated as well.  My document doesn't need to be, since the link lives outside it, but anything referencing that link, or more likely the combination of that link and my document, also needs to be updated, assuming it also wants the latest version of everything.  Updating means creating a new copy and ensuring that whatever wants to be pointing at the latest is pointing to it.  The resulting pile of corner cases and gotchas is probably resolvable, but the upshot is that the simple act of editing may have arbitrarily wide-ranging consequences.  On the web, no one but you has to know you edited a page.  That can cut both ways, but from experience it appears to be the right default [re-reading, I wonder if Xanadu defines, or could define, a special kind of tumbler meaning "the latest version of ...".  The meaning of this tumbler could change over time, even though individual objects are immutable -- D.H. Sep 2015].
• Keeping every version of everything may be expensive in some cases, though in the case of, say, this blog it wouldn't be.

These are all valid concerns, and I'm sure there are more.  The various developers must have run across them, and it would be interesting to read over the resulting discussions, if they're still out there.  However, I think there are two more fundamental issues.

First, is Xanadu trying to solve the right problem?  It's very clear that transclusion would solve problems that Nelson finds pressing, but it's far from clear there's any general demand for it, and by now that's not because no one in the field has heard of it, or even that no one in the general populace has.  Nelson explains transclusion clearly enough in the site I linked to, and "the same content knowably in more than one place" is fairly clear all by itself.  But no one seems to be asking for it.  Nelson himself says that people rarely grasp the power and importance of transclusion.  Fair enough, but such cases generally present a barrier to widespread adoption (not always -- some things you just have to try for a while before you decide they're actually cool, and some of those catch on anyway).

But more than that, Xanadu is fundamentally a closed system.  Yes, it's possible to pull in, say, a web page and treat it as Xanadu content -- pull out a quote here, reformat there and create a Xanadu-style mash-up.  But that's not transclusion.  There is no way for the owner of the web page to know that its content is also elsewhere.  To do that, the web page itself would have to be part of Xanadu.

The converse is only slightly better.  Xanadu could present a web face allowing people to view it on a web browser and create documents with links to it.  The Xanadu server could track referring sites in URLs and track who's visiting it via what page.  But that doesn't provide any assurance that any particular quote appears on any particular page, even in the absence of spoofing.  I might later delete a link, or I might simply cut and paste text in without making a link.  There may well be additional difficulties with, say, a Xanadu object pointing to a web page that links back to something else in Xanadu.  I can't be bothered to think that through at the moment.

In short, to actually realize the idea of transclusion, everyone has to cooperate.  That could work for a purely local application that never accesses the net, or for a collection of servers that all run Xanadu and speak whatever protocol it would use to maintain links coherently.  At this point, though, there is a lot of non-Xanadu information out there, and you'd have to persuade a huge number of existing systems to switch over or at least adopt Xanadu as an add-on.  Any new source of information would also have to be Xanadu-aware.  Not gonna happen.  The web, for its part, also requires computers to cooperate in using protocols, principally HTTP, but this is a much, much lower bar to clear.

The web, with its organically grown patchwork of standards and near-standards, its tolerance for missing pieces and other imperfections, and its lack of overarching authority, necessarily lacks the coherence and uniformity of something like Xanadu.  But these traits are exactly what allows it to thrive.

There's a moral to be drawn there, for those who wish information to be universally accessible to all.

100 and (I hope) counting

According to the "Blog archive" heading, this will be my 100th post to this blog. Stephen Jay Gould took a similar opportunity to tell us, finally, about his field work on Bahamian land snails. I'm more with Eubie Blake, who celebrated a 100th birthday and who said "If I'd known I was going to live this long, I would have taken better care of myself."

I won't be writing about my equivalent of Bahamian land snails -- I wish I had something so interesting to draw on -- but on something more apropos of Eubie Blake. Blake, as it turns out, really only lived to be 96 (most of us should be so lucky), and that seems as good a point as any to pick up a thread that's been running through this blog more or less from the beginning: imperfection.

When electronic computers first entered the popular consciousness sometime after World War II, their defining property was perfection. If the hero needed the answer to an intractable problem, the computer was always there, ticking away impassively. On the darker side, the flawless, emotionless and relentless android, aware of its own perfection and our human inferiority, was a stock villain.

The computer was the ultimate in modernism. Its rise coincides, perhaps not coincidentally, with the shift from modernism to whatever we're in now, variously postmodernism or late modernism, depending on whether you want to emphasize change (how modern) or continuity.

The notion of the all-knowing perfect computer dissolves rapidly on contact with actual computers. One of my early experiences in computing was meeting my dad's friend Herb Harris, who ran a computing facility in the building . I vaguely recall watching cards being punched and read, but I definitely recall suggesting that you could use a computer to store everything in the encyclopedia (and therefore, all of human knowledge).

Herb loaned me a book I still have, somewhere, on programming the IBM 360. He also gently prodded me to consider what putting an encyclopedia in a computer would mean, particularly the question of how you would find the information once you got it there. To give you an idea of the hardware of the time, the book contained a recipe for doing decimal multiplication by use of a multiplication table you could read in from external storage. I concluded that the problem was harder than it looked, but still ought to be at least partially solvable, with somewhat better hardware. Maybe I'd get back to it later ...

Now we have vast collections of textual material available via computer, and we have at least one usable way of finding the information that's there. We even have encyclopedias on line. All this information, its storage and its retrieval deal intimately in imperfection. Some examples:

• Dangling links are explicitly allowed in the web. This is not an accident but a basic tenet of web architecture. Allowing links to point to nothing means that you don't have to build a whole site at once, or even know that it will ever get built. Among other things, dangling links are a key part of the wiki editing experience (not as much fun if you just want the information, though).
• The underlying protocols the web is built on assume that messages routinely get dropped or duplicated in transit (TCP), that the information you are looking for may in fact be somewhere else (HTTP), or that the server you're ultimately trying to reach may be down (HTTP again).
• Documents are given logical addresses, not physical addresses, on the assumption that information may be physically moved, without notice, at any time. For that matter, computers themselves also generally go by logical names. There is no one perfect physical realization of the web.
• The web inherently doesn't assume that any given document is the last word on a given subject. Search engines generally give you some idea of how well-connected a page is, but this can change over time and in any case it's only a hint. Anyone can comment on a page and incorporate that page by reference.
• You can't take anything on the web at face value, or at least you shouldn't invest too much faith in a page without considering where it came from (which you don't always know) and how well it jibes with other sources of information. This sort of on-the-fly evaluation quickly becomes a reflex.
• From a purely graphical point of view, there is no definitive format for a given web page. If you try to lock everything down to the last pixel it will generally look bad on displays you didn't have in mind. If you don't, it's up to the browser at the other end to decide what it looks like, and with CSS and other tools, the viewer can have almost unlimited leeway. Nothing is perfect for everyone, so we try to get close and allow for tweaks after the fact.
• A key part of running a successful web site is managing details like backup, maintaining uptime in the face of hardware failures and (one hopes) dealing gracefully with large numbers of people pushing the limits of your bandwidth. This is hard enough that you generally want to farm it out.

There are many more examples, and probably much better ones as well. The point here is that even when it looks like the system is working just fine, imperfection is everywhere. The web tolerates this rather than trying to stamp out every last flaw, and in some fundamental ways even builds on imperfection. The result is far more powerful and useful than a computer that never loses at chess or never makes an arithmetical error.


Postscript: Herb Harris is no longer with us, but the University of Kansas student computing lab bears his name [... or it did for a while.  Somewhere around 2010 the trail seems to go cold.  Now that everyone has a phone or laptop and storage is in the cloud, there's no longer such a need to go to a place in order to compute.  The building is still there, but it now houses "Information Technology".  Sic transit ...  -- D.H. Dec 2018]

Arguing web architecture with myself

A while ago, talking about web sites as web services in the context of "Ten Future Web Trends," I said:

My guess is that tooling will gradually have more and more useful stuff baked in, so that when you put up, say, a list of favorite books it will be likely to have whatever "book" microformatting is appropriate without your doing too much on your part. For example if you copy a book title from Amazon or wherever, it should automagically carry stuff like the ISBN and the appropriate tagging.

Um, why copy book data? This is the web. Make a link with the book title for text, pointing at Amazon or wherever. Anything crawling around the web trying to make sense of this ought to be able to recognize where the link is pointing, chase it and get the other data. All the usual arguments against copying (e.g., difficulty of keeping copies in sync) apply.