Xanaduはエージェントを待っていた

Xanaduはエージェントを待っていた

今年、Ted Nelsonのことをよく考えていました。

Nelsonはコンピューティングのパイオニアであり、1965年には彼のキャリアを定義するプロジェクトであるProject Xanaduの一部として「hypertext（ハイパーテキスト）」という言葉を造りました。Xanaduにおいて、彼はコンピューティングがどのようなものになりうるかという特定のビジョンを持っていました。それを彼は「docuverse（ドキュバース）」と呼びました。彼は、ドキュメントのあらゆるバージョンを保持できるシステムを想像しました。ハイパーテキストリンクは、そのソースとデスティネーションの両方を認識し、引用は参照（コピーではなく）によって保持されるため、含まれるテキストはそのアイデンティティとソースを維持します。このコンピューティングのバージョンでは、すべてが「intertwingled（絡み合った）」そして「xanalogical（アナロジー的）」になります。私たちは、スパン（テキストの断片）レベルでの帰属表示について話しています。

xanalogicalであるとは、2つのルールに従うことです。コピーせず、常に参照する（Nelsonの言葉でtransclusion（トランスクルージョン）とも呼ばれます）。上書きせず、常にバージョン管理する。Nelsonが設計したように、Xanaduはシステムの複雑さと膨大なブックキーピングの負担自体を管理するため、ユーザーは決して忘れないシステムというメリットだけを享受できました。

無制限のブックキーピングというビジョンは、無制限のストレージと将来性のある命名スキームという現実を必要としますが、NelsonがXanaduに取り組んでいた数十年間、そのどちらも存在しませんでした。そのため、90年代にWebテクノロジーが爆発的に普及したとき、開発者は容易さを優先してxanalogicalコンピューティングを迂回しました。リンクは単純な文字列となり、ターゲットが移動すると壊れてしまいます。メンテナンスはユーザーの問題となり、システムの責任ではなくなりましたが、誰でも迅速にリリースすることが容易になり、人々はそうしました。Xanaduは新しい時代の約束から、コンピューティングで最も有名な vapourware（実現しない製品）へと色褪せていきました。

Nelsonは、Webがハイパーテキストが意図されていたものの平坦化されたパロディであると説明することにキャリアを費やしてきました。彼は正しいのですが、人々は実際にすべてのリンクをたどったり、すべてのバージョンを比較したりする必要がなかったため、それは重要ではありませんでした。私たちは落ち着きのない種族であり、他人が追求しているリンクをたどったり、バージョンを読んだりする傾向があります。平坦で十分でした。

そこにエージェントが登場しました。

エージェントが扱いにくい共同作業者であるという点が、Nelsonのシステムにとって完璧な市民である理由でもあります。エージェントは、人間が一度に頭で保持できる以上のサブテキストのレイヤーをたどることができます。例えば、引用のソース、それに関する議論、そして実行された正確なコードに添付されたスタックトレースなどです。フラグメントベースの表現は、それらの参照をロスレスにするため、テキストが変更されても各レイヤーは同じスパンにアタッチされたままになります。エージェントはこれらの次元を一緒に読み取り、人間がその作業を監査できるように引用し、毎回すべてのリンクを忍耐強くたどることができます。しかし、エージェントが見つけられるように、それらのリンクはどこかに実際に存在する必要があります。

Nelsonのビジョンを今再訪すると、DeltaDBの設計目標とDeltaの約束を認識します。人間の注意力の限界に合わせて履歴を何十年も圧縮してきた後、私たちはもっと… xanalogicalなものによってより良く提供される新しい現実にいます。

部品が存在する前にシステムを構築する方法

数年前に、Engelbartの1968年のデモを見ながら、共同編集システムを構築するためには、彼のチームがそれに依存するすべて（新しいプログラミング言語、オペレーティングシステム、ディスプレイ）を発明しなければならなかったという私の気づきについて書きました。

Nelsonも同じ問題を抱えていました（ただし、Engelbartが享受したよりもはるかに少ない資金で）。彼は、権威が発行しないコンテンツに名前を付ける方法や、削除するには安すぎるストレージなど、ほとんどの部品が存在しなかったため、Xanaduを構築できませんでした。彼のチームは何年もかけて独自のデータ構造を手作業で構築しましたが、プロジェクトは途中で頓挫しました。WiredはNelsonの物語を管理不行き届きとして描きましたが、私は彼が依存関係ツリーが存在する何十年も前にXanaduを仕様化しただけだと考えています。

依存関係ツリーは今日存在する

私たちは、他の人々の60年間のロードマップがドキュバースの失われたピース（カーネル開発、写真ストレージ、サーバーレスコールドスタート、共同カーソル）を提供してくれたおかげで、今日Deltaを構築できます。ブレークスルーが普通の仕事をしているにもかかわらず、コンピューティングの次の時代を可能にするというのは、非常に興味深いと思います。

中心のない世界のための時計。 Lamportタイムスタンプ、1978年。人間とエージェントによるすべての操作は、アクターとLamportタイムスタンプによって永遠に名前が付けられます。

嘘をつけない名前。 Merkleツリー、1979年、2005年にGitによって一般的になりました。Gitコミットハッシュは正確な不変プロジェクト状態の名前を付けます。DeltaDBは、コミット間のすべての状態に、それが下降したGitコミットと、その上に適用されたアクターとタイムスタンプのデルタIDのセットの名前を付けます。

調整なしの収束。 CRDTs、2011年に形式化され、過去10年間のZed自身の作業の中心です。Deltaワークツリーは、異なる大陸の複数の人々とエージェントによって同時に編集できます。

削除するには安すぎるストレージ。 1981年には1ギガバイトあたり数万ドルでしたが、現在は1セントです。デフォルトですべてのバージョンのすべてを保持します。

すべてを複製するネットワーク。 常時接続と高速ブロードバンドが2000年代半ばにダイヤルアップを追い越しました。すべてのスレッドはライブであり、参加者全員のマシンとブラウザでデータが複製されます。

ミリ秒で呼び出されるマシン。 FirecrackerクラスのmicroVMs、2018年。Deltaのエージェントは、会話の途中で新しい分離されたクラウドマシンをプロビジョニングできます。

永続的なコンテンツに対するビューとしてのドキュメント。 Max BrunsfeldのTree-sitter、2018年、タイプしながら再解析するのに十分な速さです。Zedで開拓されたGPUIは、フレームが描画されるたびにアプリケーション状態から新しいインターフェースを導き出すのに十分な速さです。Deltaスレッドは、永続的な構造化された履歴のライブ投影であり、平坦化されたドキュメントとして保存されるのではなく再計算されます。

一つの詳細について、キャリアを通じて夢が大きすぎると言われ続けたNelsonは、夢が小さすぎました。彼が欠けていた最後の依存関係は、新しい種類のユーザーでした。彼は人工的な読者を想像しませんでしたが、SF（AsimovのMultivacやStephensonのLibrarianなど）には存在しました。

Xanaduは数十年間、欠けているコンポーネントによってブロックされていましたが、最も必要としていたのは完璧なユーザーでした。

ドキュバースがバージョン管理で実現する理由

実際のコード作成のほとんどは常にコミット間で行われてきましたが、人間による記憶に頼っていたため、コンテキストを平坦化してもそれほど苦痛ではありませんでした（そもそも誰もキーストローク変更の完全な記録を読むつもりはありませんでした）。しかし、エージェントは何も記憶せず、すべてを読み取るため、Nelsonが正確に指定した、永続性と接続性を持つ新しい真実の源を捉える方法が必要です。

すべてのDeltaスレッドは、その約束を果たします。会話とコードは、共有された履歴の中で一緒にキャプチャされます。画面上では、ファイルは依然として一次元の文字の文字列のように見えますが、その下ではDeltaDBはそれを安定したアイデンティティを持つフラグメントとして表現します。これらのアイデンティティにより、周囲のコードが変更された後でも解決できるスパンへの参照であるアンカーを作成できます。行番号は、あるスナップショットでテキストがどこに表示されるかを示すことができますが、アンカーはスナップショット間でどのスパンを意味するかを保持します。

エージェントがその座標系をどのように構築できるかを探求してきました。以前のエージェントが繰り返し読み取り、編集し、引用し、または参照したファイルやシンボルは、次のエージェントのランドマークとなり、現在のコードに対して解決され、その理解が形成された会話にリンクバックされます。その表面表現の下にある因果関係のメタデータ（どの操作が各フラグメントを生成したか、どの先行状態に基づいているかなど）を保持することにより、DeltaDBはモデルに現在のコードだけでなく、その由来、蓄積された注意、および過去の推論をたどる方法を提供します。

Xanaduの呪いを避ける

Xanaduには、もう一つの最終的な障害モードがありました。これは自業自得でした。それは、劣ったフォーマットとの相互運用を拒否したことです。DeltaDBを世界に導入するにあたり、私たちはその間違いから学んでいます。既存のgitリポジトリと連携します。すべてのスレッドはgitブランチでもあり、Deltaを開いたことのないチームメイトは通常のレポを見ることができ、ファイルは本物なので、エージェントが使用できるあらゆるツールとシームレスに統合されます。GitHubへのリポジトリのミラーリングを継続して、まだ移行する準備ができていない人々と作業できます（これは、この移行期間中に、私たちのオープンソースIDEであるZedのアプローチです）。

EngelbartとNelsonは初期コンピューティングの預言者でしたが、私たちはどちらのビジョンもそのまま実現することはありませんでした。前者からはマウス（そして最終的にはマルチプレイヤー編集）を採用し、後者からは「hypertext」という言葉を取りました。どちらのアイデアも生き残りましたが、その作成者が想像した深さではありませんでした。私たちはまだライブセッションと永続的な記録を分離しています。議論、中間状態、意図は最終的なファイルやコミットに平坦化され、パスや行番号に紐付けられたリンクはコードの移動とともに劣化します。Deltaスレッドが両方のビジョンを同時に満たすことを願っています。ライブセッションが永続的で接続された文献を残すように、セッションと記録が同じオブジェクトであるためです。

DeltaとDeltaDBを構築するために必要だったすべてのプロパティは、私が生まれる前にNelsonによって仕様化されていました。そして、私の目標はXanaduを実現することではありませんが、長年抱いていたビジョンが人々の手に渡るのを待つ間にNelsonが経験したであろう焦燥感をまだ感じています。60年は、アイデアがユーザーを待つには長い時間です。彼らは今、ここにいます。

関連記事

Zedチームの類似ブログをチェックしてください。

---

より良いエディタをお探しですか？

macOS、Windows、LinuxでZedを今すぐ試すことができます。今すぐダウンロード！

---

採用募集中！

私たちのブログで取り上げているトピックに情熱をお持ちでしたら、ソフトウェア開発の未来を形作るお手伝いをするためにチームに参加することを検討してください。