「シンプル」は「小さい」とは違う：Unixパイプラインが実は複雑である理由
Simple Is Not Small
開発者jyn氏は、自身の講演後の質疑応答で「シンプルさを優先すべき」と答えたことに満足できず、この記事を執筆。Unix哲学が称賛する「小さなツール」は、実は結合度が高く複雑であると指摘します。単語頻度を計算するUnixパイプラインとClojureのコードを比較し、順序変更という小さな変更がUnixでは困難であることを示します。Rich Hickeyの「Simple Made Easy」を引用し、「シンプル」は「1つの編み目」であるのに対し、「複雑」は「複数の編み目」が絡み合うことだと定義。Google Driveのような大規模ソフトウェアはユーザーにとってシンプルであり、RustのstructとClojureのmapの例から、データ表現と型チェックの結合を解くことの重要性を説きます。小さいことはリソースが限られた状況では有用ですが、シンプルさは常に追求すべきだと結論づけます。
Unixツールは「小さい」が、「シンプル」ではない。
HNでの議論
87- getnormality
「Worse is Betterの興隆」という有名なエッセイ[1]と強く共鳴します。これは、（より良い）「MIT/スタンフォード流の設計」と（より悪い）「ニュージャージー・アプローチ」を対比したものです。
MIT/スタンフォード:
> シンプルさ -- 設計は実装とインターフェースの両方においてシンプルでなければならない。インターフェースがシンプルであることは、実装がシンプルであることよりも重要である。
ニュージャージー:
> シンプルさ -- 設計は実装とインターフェースの両方においてシンプルでなければならない。実装がシンプルであることは、インターフェースがシンプルであることよりも重要である。シンプルさは設計において最も重要な考慮事項である。
この記事は「シンプルさ」を「MIT/スタンフォード流のシンプルさ」（ユーザーにとってのシンプルさ）に、「小ささ」を「ニュージャージー流のシンプルさ」（開発者にとってのシンプルさ）に対応付けています。
この2つの流派の間の緊張の根源は、ユーザーと開発者の区別の曖昧さに帰着するのではないかと思います。開発者もまたユーザーです。実装のシンプルさは、開発者が直接実装に取り組むときに役立ちますが、インターフェースのシンプルさは、開発者が他の開発者の成果物を利用するときに役立ちます。
- pianopatrick
これについて、AIに基づく新しい側面を考えていました。プログラムがより小さな疎結合な「モジュール」に分割されていれば、各「モジュール」のコード全体がAIのコンテキストウィンドウに収まります。このようにして、AIはその「モジュール」のコードをすべて読み込むだけで、その「モジュール」を編集するためのすべてのコンテキストを得ることができます。ベクトル検索のようなものはあまり必要なくなるでしょう。コード1行あたり20トークンと仮定し、AIのコンテキストウィンドウが10万から100万トークンであるとすると、使用するAIモデルに応じて、「モジュール」の規模は5,000行から50,000行の間であるべきだということになります。
- hankbond
素晴らしい記事で、例は非常にわかりやすいですが、クロージャの部分を理解するのにはかなり時間がかかりました。
現在、私は非常にモジュール化されたソフトウェアを構築していますが、これは私のキャリア全体で最も設計が難しいプロジェクトです。これほど堅牢で明確に定義されたものを作るために、これまでのどの仕事でもこれだけの時間と労力を割り当てられることはなかったでしょう。このプロジェクトの多くの側面で、複雑でない抽象化を得るために、試しては捨てることを3〜5回繰り返しました。
これはまさに、vibe codingが小さな独立したスクリプトを構築するのに非常に成功し、それ以外のものには壊滅的である理由です。大きくてシンプルなものを構築するのは本当に難しいのです。
- cush
著者は「結合」という用語を使って、コードの観点からシンプルなプログラムを説明しています - 「プログラムの良いメンタルモデルを持つ必要がある」と。同意しますが、より重要なのは良いドメインモデルを持つことだと思います。優れた設計は正確に伝達し、高い実行のガルフや評価のガルフは、実際にはプログラムをユーザーにとって「複雑」に感じさせるものです。
これらの概念は、ユーザーにとって次の質問を単純化します：「自分が何をしたいかはわかっている - どうやってプログラムにそれを実行させるか？」（実行）と「プログラムが何かをした - 実際にはどのような状態なのか？」（評価）
著者はこれらの概念を目指していたと思います。特にGoogle Driveの例では、大きなプログラムが「小さな」UXを持っていることです。ドメインモデルを理解することは、ユーザーインターフェースを設計するためのはるかに強力な基盤を提供します。また、実行と評価のガルフを理解することで、ユーザーを混乱させたり圧倒したりせずに、非常に複雑に見える大きなUXを構築することができます。
- Snarwin
> Unixにはfrequenciesに相当するネイティブなコマンドはなく、sort | uniq -cが最も近い方法です。これは性能が劣るだけでなく（入力をすべてメモリに収集してから続行する必要がある）、集計を順序に結び付けています。
Unixコマンドラインの中心的な特徴の1つは、ユーザーが拡張可能であることです。「ネイティブ」なfrequenciesに相当するコマンドがないなら、自分で書けばよく、それはPATH内の他のバイナリと同じように一級市民として扱われます。これはUnixのシンプルな実装という哲学に完全に沿っています。