Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It's not a rehash. Dare uses "Worse is better" as a jumping off point to examine why Ted Nelson's Xanadu failed while the much less capable WWW succeeded. He says Xanadu was much too complex to even get out the door.

I remember visiting the Xanadu project sometime in the 80's. It was a bunch of hackers in an old house in Menlo Park, CA. I came away with the feeling that it wasnt going to succeed because it was too complex. I remember in particular the requirement for bidirectional links and thinking that it was going to require too much cooperation to maintain them. Think, every time someone linked to your site, you now had an outbound link to maintain. Did that mean that if you moved a page, you would have to update a thousand outbound links or a billion browser caches?



The thing is that seventeen rules of Xanadu, in themselves, aren't that much more complex than the WWW - The http protocol is not an uber simple thing.

Further the WWW haphazardly succeeds at being everything that Xanadu wanted to be and more, except for those characteristics which had to do with intellectual property (what is now "DRM"). Many people have described the impossibility and undesirability of DRM. One easy way to see the impossibility is to realize that a "transclusion" DRM system would require every protected piece of information to exert control over the entire system, a problem which gets harder as the system gets bigger.

It does relate to duct-tape programmers in the sense that since the WWW doesn't have the fragile global requirements of Xanadu, it can be "duct-taped" to work. But it also should impel us to go a bit beyond Spolsky in the sense that it points to designs which avoid particular inherently difficult problems rather than using simplistic formula of 'avoid any complexity'.


"The thing is that seventeen rules of Xanadu, in themselves, aren't that much more complex than the WWW - The http protocol is not an uber simple thing."

I have to disagree. Requiring secure identification of a web server means that every web site must use an SSL certificate. Most likely, the way it was intended, it must also be an identity-verified SSL cert, i.e., "Verisign" et al, not just "some SSL cert I generated last night". Requiring secure identification of the user at all times is very onerous when propagated throughout the entire stack, as it would have had to have been. Now you have to be logged in to all sites, all the time, with some sort of universally-agreed-upon protocol which would run smack into the problem that not everybody's identification needs are the same. "Every user can store documents" means you are not allowed to browse the Xanadu without paying for hosting privileges. Backwards links complicates every CMS, ever, horrifically, and also has to manifest in the protocol. And I'm not even all the way through the list, the problems keep going, but I fear boring the reader.

If you look at what they really mean (remember, these are summaries), it is night and day. An elementary HTTP server can be bashed out in an hour, and it'll work with modern browers to at least some degree. In college, writing an HTTP proxy server was a 2 hour lab assignment in networking class, to give an example of another piece of the stack. AFAIK, nobody has ever produced a full Xanadu server, despite massive amounts of effort. This is not a coincidence; this is a reflection of the almost-impossible-to-overstate difference in complexity between the two ideas.


Actually, I think you're saying the same thing I at least meant to begin with: Xanadu's requirements are fairly simple to state but extremely complex to implement.

My further point is this show a world where things are a bit muddier than Spolsky's simple/complex division.


"I remember in particular the requirement for bidirectional links and thinking that it was going to require too much cooperation to maintain them."

Although, partially, we are now starting to see this with "trackbacks" and "pages that link to this page". Of course, things would be much more complicated if this was a requirement instead of an option.

IMHO, for something to be successful in the "real world" it should have as few hard requirements as feasible, and as many applications as possible.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: