既にあった

この Part の probe のうち二つは同じオチを共有していて、それは方法自身の恥を含む。どちらも 「機能を存在へ強制する」つもりで出発し、どちらも機能が既にそこに在るのを見つけた。動く形で、 文書化までされて。「測ってから建てる」を方法の全てとする一人プロジェクトで、測るより前に 誰か —— 数ヶ月前の同じ人物 —— が既にそれを建てていたと一週間に二度発見するのは、可笑しく、 謙虚にさせ、そして一話に値する。どちらの probe も元は取ったからだ: 各々が、存在した機能の 影に潜む実物の欠陥を見つけた。

既に generic だったテストフレームワーク

一つ目の probe が欲しかったのは、assert_eq が失敗値を generic に印字するテストフレーム ワーク —— 型変数越しの show の自然な forcing program であり、順序の回の明白な続編だ。 最初の 10 分の確認: show は今日、型変数を通るか?通る —— 4 backend 全部で、順序の回が 記述したまさにあの機構に運ばれ、同じ単相化修正群によって信頼に足るものにされて。では フレームワークは?それも既に在った: 標準ライブラリの contrib 領域に Test モジュール、 show の上に建てられた generic な assert_eq 付き、十数 Phase 前の作。probe は「建てる」 から「検証する」へ旋回した —— 型変数の helper 越しのアサーション、構造的に印字される 失敗値、suite への固定。代わりに見つけたのは衛生の欠陥だった: ライブラリファイルは末尾に デモを抱えていて、import した全プログラムがデモを実行していた —— ノイズ、意図的な失敗、 他人の exit code。デモは外へ移り、規則 —— ライブラリファイルは main-free —— は contrib 全体に 適用され、同じ欠陥を持つライブラリがさらに 5 本見つかった。同じセッションが、コンパイラは 尊重するのに interpreter が黙って落とす import 検索パスのフラグも捕まえた —— このプロジェクトが CLI の縫い目で見つけ続ける、interpreter/コンパイラ非対称のもう一匹だ。

既にフラットだった構文

二つ目の probe は 8 段の fallible 設定ローダを 3 通りに書き、エラーハンドリングの書き味を 測った。ネストした match のピラミッドは予想どおり酷かった —— 7 段の深さ、同じエラー転送の arm を 7 回複写、そして書き手は閉じ括弧を二度数え間違えた。これも測定値だ。combinator 連鎖は ましだが inside-out に読める。probe の設計ノートは修正案を素描した: result を unwrap するか エラーを早期 return する束縛形。それから、最初に来るべきだった docs の grep: その形は在る。 let x = e?! in body —— option 版の ? も —— は十数 Phase 前に出荷され、patterns ガイドに 専用の節を持ち、電卓の example で 5 回使われている。それで書き直すと、パイプラインは束縛の フラットな列、13 行、ピラミッドなし。probe の唯一の実発見: ?/?! の let は、言語で唯一 ; を in の代用として拒む let 形だった —— 他の全ての let は両方の区切りを受ける。パーサの 2 行で非一貫性は閉じた。

教訓の定式化

「既にあった」が一度なら小話だが、一週間に二度は方法についてのデータだ。probe 群は runtime を 尋問するよう設計されていた —— builtin を grep し、式に型を付け、プログラムを走らせる —— 能力の gap はそこに住むからだ。だが機能は一段上、構文とライブラリに住む。probe の正直な第一歩は、いまや プロジェクトのノートに書き込まれている: probe を書く前に docs を grep せよ —— 言語 リファレンスの糖衣一覧、patterns ガイド、contrib の README 表。優しい読み方もある。作者が 「足そうとしたものを既にやる」と繰り返し発見する言語は、小さな敷居を越えたのだ: 作者の作業記憶 より大きくなった、という敷居を。文書はそのためにあり、二つの probe はどちらも、文書と —— 機能の 周りの縫い目とを —— 見つけたときより良くして去った。残る二話は、本当に存在しなかったものへ戻る: 言語に日本語を打ち込むと何が起きるか、そして百万要素で何が起きるか。