As much as Ted comes across as a cross between Grampa Simpson and the crazy cat lady, he has a lot of good ideas that would probably have been really successful if he’d applied them to source code rather than spending his life rallying against the WWW and fighting about patents and such.
The infrastructure he’s advocating is serious work to implement with any sort of performance, if it could be done at all on a world-wide scale.
Any user interface cooked up by his teams over the years has been, ah… “not great”
Most browsing / writing users will never need 99% of the functionality his structures give you, and will certainly never pay the price of the cognitive load those features bring with them.
But, those features (tracking transclusions, advanced versioning and two-way links, etc) would be super-useful for source code, and programmers are the kinds willing to give up some ease of use for power- I mean, most of us use git, and some weirdos even like it.
Edit: Additionally, when limited to an individual or limited group of codebases, the performance issues could be solved over time as the software was applied to larger corpuses (corpii? I dunno)
I don’t think performance in infrastructure is much of an issue here. The basic structures are pretty easy to implement, once you understand them. (In fact, since leaving the project, I’ve done open source versions of several.)
There are a couple things getting in the way of wider adoption.
Ted still approaches the project like he’s running a software company in the 80s, although the developers are as far as I know all volunteers. So, technical details that might catch the imagination of developers are often kept secret or simply not publicized in useful ways.
A lot of these technical details are things worked out decades ago that make the infrastructure side trivial and performance good.
One of these days I’d like to give a conference lecture or something explaining the difference between outsider’s views of how certain xanadu concepts would naturally be implemented (often based on the web or based on an understanding of client/server or something) and how different internal prototypes actually work, because it would be eye-opening for a lot of people.
Ted still thinks he can become a middle-man in this system and make a healthy profit. (Had things gone better at Autodesk, this probably would have been true. But, he’s in his 80s now.)
Having open source & fully or mostly peer to peer implementations (using IPFS or another CAN/NDN for storage) would make everybody’s lives easier here, but would make it impossible to turn it into a subscription service, because nobody would need hosting.
Demos don’t get circulated until they meet pretty high standards of UI polish, from Ted’s point of view – and Ted likes a lot of glitz and glamor, even when it’s tacky. (He wore a purple tuxedo to his own wedding, at which he sang show-tunes.)
Results: (1) all public demos look tacky, (2) almost all internal work never gets released, (3) internal work that is more functional gets passed over for release in favor of less-functional stuff that makes use of 3d or translucency or has smooth animations.
There are a lot of bad, confusing, & incomplete explanations of Xanadu concepts floating around, mostly because it was determined that (even in a book like Literary Machines) it was too much to throw at somebody at once. But, all the core concepts are deeply intertwingled in a way where implementing one of them in isolation without understanding how the others work with it is liable to produce an underwhelming result.
For instance, transclusion is the basis for versioning and for remixing, and without it, transcopyright would be stupid; transclusion itself would fall apart if we didn’t use overlay/external markup, which itself is based on overlay links. So, at the very least, to implement any part of a transliterature system, you need to understand: transclusion, EDLs, and overlay links. All of that also relies upon permanent addresses with static content, etc.
Somebody who sees some of these ideas in isolation will try to tack it on to web concepts like host-based URLs, embedded SGML-like markup, and view-based versus ownership-based micropayments, and will fail miserably because web tech is incompatible with hypertext on a fundamental level several times over & the limitations are awkward to work around.
Ted wants creative control, but he’s not organized enough to be a good manager, and he’s working with volunteers.
(He’s not a bad manager in the sense of being abusive or anything. He just misplaces spec documents on a regular basis and rewrites them from memory with tiny sometimes-accidental changes, is sometimes late for meetings or forgets about them entirely, gets side-tracked discussing Stanley Kubrick or cellular automata during meetings, forgets about previous instructions or forgets to send instructions, or other essentially ADHD-related issues.)
Since he’s working with volunteers, he gets some pushback on the creative control angle, which can be upsetting when the person he’s working with also doesn’t have a strong understanding of the fundamentals of translit, because he often gets pushback in the direction of breaking translit and making it more like the web.
As much as Ted comes across as a cross between Grampa Simpson and the crazy cat lady, he has a lot of good ideas that would probably have been really successful if he’d applied them to source code rather than spending his life rallying against the WWW and fighting about patents and such.
Yeah, he made a big mistake by not learning to code back in the 60s when he first had the opportunity.
As a humanist, Ted Nelson is absolutely brilliant, and we would all benefit greatly if he could get his ideas implemented further.
As a programmer or manager of programmers, unfortunately, he doesn’t seem to grasp just why his ideas are not easily feasible.
There’s a few major problems:
But, those features (tracking transclusions, advanced versioning and two-way links, etc) would be super-useful for source code, and programmers are the kinds willing to give up some ease of use for power- I mean, most of us use git, and some weirdos even like it.
Edit: Additionally, when limited to an individual or limited group of codebases, the performance issues could be solved over time as the software was applied to larger corpuses (corpii? I dunno)
I don’t think performance in infrastructure is much of an issue here. The basic structures are pretty easy to implement, once you understand them. (In fact, since leaving the project, I’ve done open source versions of several.)
There are a couple things getting in the way of wider adoption.
A lot of these technical details are things worked out decades ago that make the infrastructure side trivial and performance good.
One of these days I’d like to give a conference lecture or something explaining the difference between outsider’s views of how certain xanadu concepts would naturally be implemented (often based on the web or based on an understanding of client/server or something) and how different internal prototypes actually work, because it would be eye-opening for a lot of people.
Having open source & fully or mostly peer to peer implementations (using IPFS or another CAN/NDN for storage) would make everybody’s lives easier here, but would make it impossible to turn it into a subscription service, because nobody would need hosting.
Results: (1) all public demos look tacky, (2) almost all internal work never gets released, (3) internal work that is more functional gets passed over for release in favor of less-functional stuff that makes use of 3d or translucency or has smooth animations.
For instance, transclusion is the basis for versioning and for remixing, and without it, transcopyright would be stupid; transclusion itself would fall apart if we didn’t use overlay/external markup, which itself is based on overlay links. So, at the very least, to implement any part of a transliterature system, you need to understand: transclusion, EDLs, and overlay links. All of that also relies upon permanent addresses with static content, etc.
Somebody who sees some of these ideas in isolation will try to tack it on to web concepts like host-based URLs, embedded SGML-like markup, and view-based versus ownership-based micropayments, and will fail miserably because web tech is incompatible with hypertext on a fundamental level several times over & the limitations are awkward to work around.
(He’s not a bad manager in the sense of being abusive or anything. He just misplaces spec documents on a regular basis and rewrites them from memory with tiny sometimes-accidental changes, is sometimes late for meetings or forgets about them entirely, gets side-tracked discussing Stanley Kubrick or cellular automata during meetings, forgets about previous instructions or forgets to send instructions, or other essentially ADHD-related issues.)
Since he’s working with volunteers, he gets some pushback on the creative control angle, which can be upsetting when the person he’s working with also doesn’t have a strong understanding of the fundamentals of translit, because he often gets pushback in the direction of breaking translit and making it more like the web.