OS全体がこれらのソースファイルを中心に構築されてるんだよね。一方で、Unixの哲学は「プレーンテキスト」を解析するコードが組み込まれたツールが設計されて初めて「繁栄」するんだ。

その通り。こういうアイデアは何度も出てくるけど、コストと利益が全然合わないんだよね。シンプルなフォーマッターを使うのを避けるために、信じられないほど複雑なツールを追加してるだけだし。全ての開発者が自分の好みでコードを見れることなんて、そんなに重要じゃないと思う。私が関わったチームでは、標準のスタイルガイドを使って、フォーマッターで強制してるけど、全員が全てのルールに同意するわけじゃない。それでも、慣れちゃうんだよね。コードのフォーマットについて議論したりこだわったりするのは、単なる無駄なバイクシェディングだと思う。

もし共通の中間エンコーディングがテキストで、バイナリじゃなかったらどうなる？そうすればgrepやdiff、sedはまだ使えるよね。ASTに基づいて動作するフォーマッティングツールがあれば、チェックインされたコードは特定のASTのための標準的な形式にできる。エディタはASTを解析して、ユーザーの選択した異なるフォーマットでソースを表示し、ファイルをディスクに書き込むときに標準形式に変換できるんだ。

DIANA irから元のソースコードみたいな形に戻すことってできるの？その逆変換の結果をgrepしたりできるし…

ソースを標準フォーマットで保存して、各開発者に合わせて unpack するなら…なんで標準フォーマットが普通のソースコードでなきゃいけないの？全てのツールはテキストバックエンドでも存在できるし、grepやsedのサポートもタダでついてくるよ！

もし初期のスペース幅が好きなエディタで設定できるなら、タブを好む人たちは他に何か意見があるのかな？もちろんあるよ。だってタブ幅は動的に柔軟だから、初期のスペース幅だけじゃ足りないんだ。

Grepやdiff、sed、行ベースの非セマンティックマージは、コードを操作するにはひどいツールだよ… それらでさらに深みにハマるより、何かもっと良いものを考える理由があった方がいいかもね。

これが機能するイメージは、gitフィルターみたいな感じだね。バージョン管理からチェックアウトすると、好みのフォーマットでテキストに変換されて、それを期待通りに扱うことができる。ステージングすると、保存された表現に変換される。gitでは、これはsmudgeとcleanフィルターを使って行われる、git LFSのようにね。フォージやその類のためのビューアもあって、必要に応じて保存された表現を解釈するように作られてる。テキストで作業するけど、そのテキストは標準の保存表現じゃない。構造が変わった時だけdiffが出てくる。事前コミットのリンターフックでもほとんど同じメリットが得られるけどね。

テキスト以外のものは、grepやdiff、sed、バージョン管理をあまり効果的にしないよね。UNIXの設計ミスかもしれないけど、テキストにこだわりすぎてる気がする。

テキストは確かに重要なポイントだけど、私たちが短期的な視野で谷に入ることを避けているせいで、ローカルな問題にハマっていると思う。あなたの例は構造的な知識があるコードに対してはうまく機能するよね：- grep: シンボル検索（テキストのgrepより100倍使ってる）や https://github.com/ast-grep/ast-grep - diff: https://semanticdiff.com（他にもいろいろ）、つまり：ノイズの多い構文の変更を隠して、移動したコードを捉えようとする。投影プログラミングがあれば、コードが移動することの表現力がもっと高くなると思う。- sed: https://npmjs.com/package/@codemod/cli - バージョン管理：Unisonのような言語を見て、ここでできる面白いことを探るのがいいと思う。特にライブラリに関しては。一般的な例としては、非意味的な変更（順序の変更や無関係な空白など）による競合がないこと。