Project Xanadu: さらに振り返る

JS, design, meta Project Xanaduの成功と失敗に関する回顧録：設計の反復、意味のあるユースケース、または実用性の欠如が、価値あるビジョンが有用なものへと成熟するのを妨げた。（そして私のアプローチとの対比。）2025-05-05 完了 確実性：可能性のある重要度：4 参考文献 2024年12月、サンフランシスコ訪問中に、私はそこでしか起こり得ないようなパーティーに急遽招待される幸運に恵まれました。それは、ハイパーメディアの先駆者テッド・ネルソンの1974年のマニフェスト「Computer Lib/Dream Machines」の50周年を祝うもので、Project Xanaduのハイパーテキストのビジョンを称賛するものでした。私は20年間英語のWikipediaに貢献しており、15年間Gwern.netで断続的に作業してきたので、ハイパーテキストについて強い意見を持つ人々が集まるパーティーを欠席するわけにはいきませんでした。 ホストのジェームズは、ネルソンの記念品を驚くほど豊富に用意してくれていました。その本（実物は私が思っていたよりもはるかに大きく印象的で、拡大鏡が必要なコンパクトOEDに似ており、それも提供されていました）や、ネルソンの1997年の著書「The Future of Information」だけでなく、彼のスワースモア大学時代のmimeograph雑誌のコピー、そして何よりも印象的だったのは、様々なXanadu実装のコピーを実行しているいくつかのビンテージコンピューターでした。テッド・ネルソンは87歳でまだ生きていましたが、残念ながら出席できませんでした。幸いなことに、参加者の一人はAutodesk時代のXanaduの元プログラマー（1988年〜1993年頃）であり、彼の話を聞くことができました。 彼らの話は、私たちがコンピューティングの初期時代をロマンチックに捉えがちですが、当時のハードウェアの制約は非常に厳しく、生産的な開発を困難にしていたことを思い出させてくれました。過去のソフトウェアシステムにおけるいくつかの失望は、制限を回避するためにどれだけの時間と創意工夫が費やされたかを思い出すと、より理解しやすくなると思います。例えば、McIlroy 1982は、1MB未満のRAMに収まる有用なスペルチェッカーを得るために数ヶ月にわたる巧妙なアルゴリズム設計と最適化を行ったことを正当に誇りに思っていますが、今日ではそれをJavaScriptで数行で書くでしょう（そしてLLMによって行われるでしょう）。 例えば、彼はXanaduをSmalltalkでプロトタイプした（これは、生産性が高く、快適な言語/OSであり、そのオブジェクト指向モデルがハイパーメディアに美しく適合するため、理にかなっていました）が、その後C++にクロスコンパイルしてコンパイルする必要があったと説明しました…それはコンパイルに約1週間かかりました。1分でも、1時間でも、1日でもなく、1週間です。（そして、私はGwern.netの数時間に及ぶコンパイル時間が私の開発速度にとって悪いと思っていました！）彼はまた、C++のくだらなさやコンパイルの問題に対処するために多くの時間を無駄にしなければなりませんでした。 私たちが目にしたPCでこれを実行できるようにすること自体が挑戦であり、パーティーの理由の一つでした。正直に言うと、Autodesk時代のXanaduで、数人のフルタイムのマンイヤーを費やしたにもかかわらず、なぜこれほど成果が少なかったのか疑問に思ったことがありました。一方、Gwern.netのクライアントサイドのトランスクルージョンやポップアップ機能を実装するのは、Said Achmizにとっては通常数日の作業でした。しかし、当事者からいくつかの武勇伝を聞くことで、物事を正しく理解し、当時の人々がいかに信じられないほどコンピューティング能力に乏しかったかを思い出すのに役立ちました。（CPUよりもストレージの方が悪かったかもしれません。必要なPDF、PostScript、HTMLファイルをホストできることを当然のことと思っていますが、私のホストしているドキュメントのかなりの割合は、1990年代中盤のPCの総ハードディスク容量（おそらく50MBのハードドライブ）を超えています。一方、Gwern.netのエッセイのMarkdownソースファイル自体は約40MB、注釈はその倍、そして最終的なサイトは221,438MBです！） 大学の雑誌は驚きであり、めくってみると楽しかったです。若い頃のテッドはすでにたくさん書くのが好きで、自分のアドバイスを配っていました。誰かが、ネルソンはハリウッド監督になることを夢見ており、代わりにテクノロジーに進んだことを後悔していると言いました。それは理にかなっており、彼のオートール的なソフトウェア開発アプローチ（「プログラマーではない」と50年経っても主張することなど）や、「編集決定リスト」のような映画編集の比喩の使用を説明していると思いました。 私も「Computer Lib/Dream Machines」をきちんと読む機会がなく、数ページをめくってみました。複数のコラムがあり、できるだけ多くの情報を詰め込もうとした、この大きな本を見るのは興味深かったです。ネルソンは読者がコンピューターについて何も知らないと仮定し、バイトやファイルのような基本的な概念をゼロから説明しなければなりませんでした。（年配の方なら本当に拡大鏡が必要でしょう。）後の（そしてはるかにマイナーな）著書「Future of Information」も、章の構造がユニークで、複数の順序で読むことができ、中央に要約章がある点で興味深かったです。 Yuxi Liuは、Xanaduが、データベースとAIに密接な関係を持ち、カリスマ的なリーダーが一度も考えを変えず、オープンソースを嫌い、同様の「病的な科学」の兆候を示した、もう一つの有名な長期間にわたる大規模プロジェクト、Douglas LenatのCycに似ていると指摘しています。そして、それを考え、Xanaduの資料を再読すると、私も同意します。 私はXanaduのPCを briefly 触ってみましたが、それが動いていることに感心しましたが、私やパーティー参加者のほとんどはそれから離れてしまいました。UIが異質すぎたのです。ジェームズがデモを見せるか、それに類するものを見る必要がありました。ハイパーテキストシステムは、特に誰も25年以上使ったことのない、あるいは一度も使ったことのないOS上で動いているコンピューターでは、即時の探索には向きません。 しかし、画面に表示された典型的なProject Xanaduのデモ、創世記の冒頭部分を見て、有名な行が右にジグザグに伸びてトランスクルージョンやコメントを示しているのを見て、突然の気づきを得ました。「なんてことだ—全く読めない。」線は混乱したノイズであり、特にそれらが交差している（サイドノートレイアウトにおける永続的な問題であり、アウトラインによってさらに悪化していました）と、読みにくくなっていました。画面が非常に小さかったため、「サイドノート」のどれも読むことができませんでした。スクロールしているだけでも、多くの可能な位置で、線のために何も読むことができませんでした！何も読めないことが多いドキュメントUIが、どうして良い考えだと思われたのでしょうか？UIはただひどく、決して機能しなかったでしょう。私の4Kモニターのような大きな画面でさえ、私はそれを望みません。 そして、テキストの選択について考え、UIが本当の問題ではないことに気づきました。そして、何十年もの間、問題はチームでもありませんでした。並列範囲トランスクルージョンの概念全体は、問題を求めている解決策なのです。範囲指定されたトランスクルージョンとコメントは、創世記の本文には意味がありました。そこでは各行に詳細なコメントがあり、多くの聖書批評が複数の矛盾するテキスト（有名な自己矛盾する複数の創造の物語など）からどのように編集されたかを整理しています。しかし、私は「ねえ、Gwern.netでもサイドノートや範囲トランスクルード/コメントを双方向バックリンク付きでできるし、私の「Suzanne Delage」短編小説分析でもやっている！」と考えたとき、突然気づきました。私たちはできるのですが、ほとんどやりません。なぜなら、誰も本当にそれを必要としていないからです。 これは、テッド・ネルソンの「並列文書の例」を見ると特に顕著です。テキスト批評（聖書、ハムレット、「羅生門」対映画羅生門）、バージニア権利章典が米国権利章典に影響を与えたという引き伸ばされた例、そして非常に疑わしい例—聖人のリスト、組織内の電話の会話、コメディテレビのエピソード…？世界中のほとんどのテキストは、詳細に検討される必要はなく、特定の行や段落がトランスクルードされる必要もありません。ほとんど誰もタルムードのような注釈を、何層にも重ねて行っていません。引用のほとんどすべての実際の例は、対象全体への引用です。そして、それらであっても、99％を見たいとは思わないでしょうし、良い1％をどのように整理すればよいかわからないでしょう。なぜなら、それぞれ異なる目的を持っている可能性があるからです。（オンラインコメントを一度見てみてください：日付順、人気順にソートしますか？