どこで痛むかを選ぶ

この時点で言語は心地よい問題を抱えていた：自分のテストを通り続けるのだ。セルフホストのコアは 証明され、導出された振る舞いは完成し、馴染んだドメインで建てる新しいアプリ —— また一つ web サービス、また一つコマンドライン filter —— は、どこが悪いかを明かすでなく言語が問題ないと確認する ばかりだった。それは心地よい場所で、留まるには危険な場所だ、なぜならプログラムは自分自身の形が 触れる痛みしか surface できず、同じ国の四つのプログラムはやがて全て問題ないと合意する —— それがそう だからでなく、すでにすることの先へ決して届かないから。dogfood 法はプロジェクト全体のエンジンだったが、 アイドリングしていた。

方法を自分自身に向ける

直しは、方法を別の問いに向けることだった。「何を建てるべきか？」でなく「どこで建てることが痛む か？」—— なぜなら痛みが signal で、目標はそれを待つでなく意図して誘発することだったから。この 再構成は、良い次プロジェクトの基準を変える。良いのは最も有用なツールを生むものでなく；言語が 持たない能力にまっすぐ歩み込み、それを終えるのにその能力を育てることを要するものだ。ツールは 餌で、欠けた力が獲物だ。

gap を推測でなく測る

肝心の規律は、それらの gap を想像でなく測定で見つけることだった。座って言語に何が欠けているか想像 するのは容易で、間違えるのも容易だ —— 実は無い gap を発明したり、ある gap を見落としたり。だから 想像でなく、runtime を直接尋問した：別プロセスを起動する手段を grep —— 無し。raw な端末入力、行を 待たない 1 キー押下を grep —— 無し。専用の bytes 型、あるいはゼロ埋め込みの文字列が壊さない バイナリ処理を grep —— 無し、バイトを 16 進テキストに符号化する workaround だけ。これらのそれぞれが 仮定でなく実コードに照合され、それぞれが実の、確認された不在として返ってきた。何も見つけない grep は、 どんな量の推測よりも正直なフロンティアの地図だ。

曖昧な計画が精密なリストになる

その測定から短く具体的なリストが落ち、各項目はそれが強制する一つの能力と対にされた。ビルドツール やタスクランナーは他のプログラムを走らせる力なしに存在できない —— だからプロセス制御を言語に 引きずり込む。対話的な端末プログラム —— 小さなゲーム、テキスト UI —— は raw なキーボード入力なしに 存在できない、だから端末制御を強制する。バイナリ形式の parser —— そしてここでの最も鋭い選択は コンパイラ自身の WebAssembly 出力で、言語が自ら emit するまさにそのバイナリを読むことになる —— は正直なバイナリ処理なしに存在できない。そして frontend bindings で描画・駆動されるブラウザ ゲームは、人が実際に遊べるものを兼ねつつ対話的な web 入力を行使する。四つのツール、四つの力、 一行書く前に各 gap が名づけられた。

なぜ「違う痛み方」が全ての要点か

四つを貫く統一のアイデアは、各々が互いと、そしてそれ以前に建てた全てと違う場所で痛むよう選ばれた ことだ。以前のアプリケーションは全て一つの領域 —— 入力と出力に縛られた string と record の仕事 —— に住み、その痛みを徹底的に地図化していた。この四つは意図してその領域を去った：一つはプロセス制御へ、 一つは raw 端末 I/O へ、一つはバイト へ、一つはブラウザへ。それらを広げる要点はカバレッジで、 言語が四つのコード生成 backend を一致に保つのと同じ精神だ。gap は正しい形のプログラムが歩み込んだ ときにだけ現れるので、gap を見つける道は、意図して違う形のプログラムを意図して違う方向へ送ることだ。

この Part で続くのはその四つのツール、一つずつ、そして各々が存在へ強制した力だ。痛みの一部は 予測どおりの場所にあり；一部はまったく別の場所にあった、コンパイラに長く隠れていた幾つかのバグと、 言語への修正がそれで書かれたプログラムを静かに壊した一つの自傷を含めて。その全ては、ここで為された 同じ決定から来た：言語が問題ないと確認するのをやめ、どこが問題かを探しに行く、という。