「UNIXという考え方」を読んだ

投稿時刻2023年4月22日 06:40

「UNIXという考え方―その設計思想と哲学」を 2,023 年 04 月 22 日に読んだ。

目次

メモ

1.1 UNIXの考え方: 簡単なまとめ p8

UNIXの考え方におけるそれぞれの定理は、一見簡単なものに見える。
また、実際に簡単なので、その重要さを見過ごされることも多い。しかし、だまされてはいけない。
一見簡単に見えるこれらのアイデアが一貫して行われると、 信じられないほど効果的なものとなる。
ここで、UNIXの考え方の輪郭を明確にしてもらうため、それぞれの定理について簡単にまとめておく。
本書の残りは、これらの解説に費やされる。

1. スモール・イズ・ビューティフル (小さいものは美しい)
小さいものは、大きいものにはない利点がいくつもある。
小さいもの同士なら、簡単に独特の便利な方法で組み合わせることができるというのもその一つだ。

1. 一つのプログラムには一つのことをうまくやらせる
一つのことに集中することで、プログラムに不要な部分をなくせる。
不要な部分があると、実行速度が遅くなり、不必要に複雑になり、融通が効かなくなる。

1. できるだけ早く試作する
あらゆるプロジェクトにおいて、試作は重要だ。
一般的に試作は設計全体のうちのほんの一部として扱われているが、UNIXにおいての試作は、効率的な設計には欠かせない重要な一部だ。

1. 効率より移植性を優先する
UNIXが移植可能なオペレーティングシステムという新境地を開拓したとき、これはすごいニュースだった。
現代のソフトウェア設計では、プログラムに移植性があることは当たり前のこととして捉えられている。
これは、 UNIX の考え方のうち、他のシステムにも広く受け入れられている一つの例だ。

1. 数値データはASCIIフラットファイルに保存する
移植性のあるプログラムは重要だ。
しかし、移植性のあるデータも移植性のあるプログラムに勝るとも劣らず重要だ。
従来の移植性に関する議論では、デ ータの移植性という視点がいつも無視されてきた。

1. ソフトウェアを梃子 (てこ) として使う
再利用可能なモジュールの重要性について、たいていのプログラマは表面的にしか分かっていない。
プログラムの再利用は、ソフトウェアの梃子を最大限に活用した強力な考えだ。
UNIX の開発者たちは、この考え方に従って、常に多くのアプリケーションを比較的短期間に開発してきた。

1. シェルスクリプトによって梃子の効果と移植性を高める
シェルスクリプトは、ソフトウェアの梃子を活かすと同時に移植性も高めるという二つの効果がある。
可能なときは常に、C言語ではなくシェルスクリプトを使うべきだ。

1. 過度の対話的インタフェースを避ける
いくつかのコマンドは、「ユーザーを拘束する」インタフェースを持つ。
そのコマンドを実行してしまうと、実行中に他のコマンドを実行することはできない。
つまり、そのコマンドの実行中は、ユーザーはそこを離れられなくなってしまう。
そのため、この類のものを「拘束的」 ユーザーインタフェースと呼ぶ。

1. すべてのプログラムをフィルタとして設計する
ソフトウェアの本質は、データを処理することで、生成することではない。
その能力を最大限に発揮するためには、プログラムをフィルタとして動作するように設計すべきだ。

ここまでの項目は、UNIXの開発者たちにとって、その教義にも匹敵するものだ。
他のUNIXに関する書籍にも取り上げられているだろうし、UNIXの基礎をなす考え方として広く受け入れられている。
これらの定理を身に付けていれば、 「UNIX人」として認められるだろう。

次に、いくらか重要度の低い10の小定理を挙げる。
これらは一般的に、 UNIXの考え方の一部として捉えられているが、
必ずしもすべてのUNIX関係者が教義として受け入れているわけでもないし、
厳密にいうとUNIXの特徴とはいえないものも含まれている。
それでも、これらは「UNIX文化」の一翼を担っているといっていい。

1. 好みに応じて自分で環境を調整できるようにする
UNIXのユーザーは、自分の思いどおりに環境を手直しすることを好む。
UNIX アプリケーションの多くは、その対話スタイルの選択についてユーザーに広い自由度を与えている。

1. オペレーティングシステムのカーネルを小さく軽くする
新機能の追加要求が次から次へと出てくる中でも、
UNIXの開発者たちはオペレーティングシステムの中心部分を小さく軽く保つことを好んできた。
もっとも、どんな時にも達成できたとはいえないが、それでもこれは目標の一つといっていい。

1. 小文字を使い、短かく
アルファベットの小文字を使うのがUNIXの伝統だ。
もともとはそうする理由があったのだが、 その理由がなくなってしまった現在でもUNIXユーザーの好みは変わっていない。
UNIX ユーザーが暗号のような小文字のコマンド名を好むのは、誰かに強制されているわけではなく、自分がそうしたいからだ。

1. 木を守る
UNIXユーザーは紙のドキュメントを嫌う。
すべてのテキストファイルをコンピュータに保存して、強力なツールでそれらを操作するのだが、
このことには十分な理由がある。

1. 沈黙は金
UNIXのコマンドは、詳細なエラーメッセージを出すべきときにも、悪名高いほど沈黙を守る。
UNIXに慣れたユーザーはそれが一番いいと考えるのだが、
他のオペレーティングシステムのユーザーにとっては、ちょっととんでもないことに思えるだろう。

1. 同時に考える
たいていの仕事は、いくつかの小さい部分に分けられる。
これらの小さい部分を同時に実行すると、大きな一つの仕事にかかるのと同じ時間でより多くの仕事ができる。
現在のコンピュータ業界のトレンドの一つがこの並列処理だ。
対称マルチプロセッシング (SMP)の分野では、さまざまな活動が活発に行われている。

1. 部分の総和は全体よりも大きい
小さい部品を集めて大きなアプリケーションを作るほうが、
大規模プログラムを単体で構成するよりも柔軟性に富み、したがってより役に立つ。
どちらのアプローチでも同じ機能は達成できるかもしれない。
しかし、先のことを考えると、小さい部品の集合によるアプローチのほうが有利だ。

1. 90パーセントの解を目指す
どんなことであれ、 100パーセントうまくやることは大変だ。
90パーセントのことだけをうまくやれるようにするほうが、はるかに能率的であり費用対効果も最も高い。
UNIX 開発者は、 対象ユーザーの90パーセントが満足する解を目指す。
残りの10パーセントには自分で何とかしてもらうしかない。 

1. 劣るほうが優れている
生き残るのは「最大公約数」的なシステムだと、UNIXファンは信じている。
高級品ではないが効率的なもののほうが、高品質で高価なものよりも断然受け入れられやすいだろう。
PC互換機の世界が、UNIX界のこのアイデアに従って大きな成功を収めつつある。

1.  階層的に考える
UNIXユーザーと開発者とは、物事を階層構造で整理するのが好きだ。
例えば、UNIXでのディレクトリ構造は、ファイルシステムに適用された最初の階層構造アーキテクチャだ。
UNIXはこの階層的な考え方をさらに発展させ、ネットワークサービスでの命名法やウインドウ管理、
オブジェクト指向開発など、他の分野にも影響を及ぼした。

UNIXにおける定理とでもいうべきものについて一通り見てきたが、
「なにを大騒ぎするほどのことがあるのか」と思っている方がいるかもしれない。

「スモール・イズ・ビューティフル」なんてたいしたことじゃない。
「一つのことをうまくやろう」それはとても狭量な見方ではないのか。
「効率より移植性を優先」これのどこが世界を変える考えなのだろうか。

ここにUNIXの全てがあるのだろうか?

2.1 定理 1:スモール・イズ・ビューティフル p14

プログラムを書くときは小さなものから始めて、それを小さなままに保っておく。
簡単なフィルタプログラムでも、グラフィックスパッケージでも、
巨大なデータベースを構築するときでも、同じく小さな実用的なプログラムにする。
一つの巨大なプログラムにしようとする誘惑に負けないで、シンプルさを追及する。

伝統的なプログラマは、巨大なアメリカンプログラムを書きたいという欲求を内に秘めていることが多い。
このようなプログラマがプロジェクトに携わると数週間、数ヵ月、あるいは数年かけてでも、
世界中のすべての問題を一つのプログラムで解決しようとする。

コスト的にビジネスに見合わないだけでなく、何よりも彼らは現実を無視している。
現実には、その場かぎりの小さな解決策でも解決できない問題はそれほど多くはない。

ほとんどの場合、問題を完全に理解していないから巨大な解決策を実装しようとしてしまうのだ。

2.3 定理 2:一つのプログラムには一つのことをうまくやらせる p23

最良のプログラムは、クストーのレイク・フライのように、生涯において一つのことをうまくやるプログラムだ。
プログラムはメモリにロードされて、所定の働きをし、次の単一機能のプログラムの実行のために道を譲る。

簡単に聞こえるが、ソフトウェア開発者たちが単一機能プログラムを作り上げることだけを追及し続けること、
これがいかに難しいことかを知ったら驚くかもしれない。

ソフトウェア開発者は、業界でいうところの「しのびよる多機能主義」の犠牲になってしまう。
プログラマは、シンプルなアプリケーションを書くかもしれない。
しかし、彼のクリエイティヴさが新機能や新しいオプションを付けてしまうのだ。
間もなくプログラムは、もともとの目的にちょっとずつ機能を付け足したゴタまぜのものになってしまう。

第3章 楽しみと実益をかねた早めの試作 p28

マーケットを負かすことは非常に難しいが、成功例がわずかながらある。
フィデルティー・マゼラン基金の有名なマネージャであるピーターリンチは、1980年代にものすごい業績を上げて顧客に巨富を与えた。
「オマハの神託」で知られるウォレン=ビュッフェは、バークシャー・ハザウェイの株主たちに莫大な利益をもたらし、
サー=ジョン=テンプルトンは、世界中の投資機会に目を光らせて巨万の富を築いた。

これらの成功にもかかわらず、彼ら伝説的な投資家たちでも、常にうまくいったわけではないことを率直に認める。
自信を持って買った株が一年も経たないうちに50%以上も下落したこともある。

また 「逃した魚」も大きい。
全く見込みのないような株が1000%以上も上昇したことだってあるのだ。
業績が群を抜いている彼らでも、まだ学ぶことは多い。

他の職業でも同じことだ。
医者は、最新の研究成果に追いつくように常に努力しなければならない。
会計士は、新しい税制について学ばなければいけない。
弁護士は、最近の判例について勉強しなければいけない。
保険数理士やセールスマン、トラックの運転手、組み立て工、配管工、電気工、裁判官、研究者、野犬狩り、エンジニア、誰もが学び続けなければならない。 

学習曲線からは降りられない 
考えてみてほしい。
全く失敗をせず、常に正しい結果を知っている人間に会ったことがあるだろうか?
全くいないとは言わない。
しかし、稀にしかいないのではないか。
そのような能力を身に付けるには、ハードワークと勉強とを裏付けとして、その上に一つかみの幸運が必要だろう。

ソフトウェア技術者たちは、特に急激な学習曲線を求められている。
最初から正しくソフトウェアを書くことは非常に難しい。
ソフトウェアのエンジニアという職業には、継続的な改訂作業がつきものだ。
試行錯誤は当然であり、嫌気がさすようなやり直し作業を数えられないくらい行って初めてアプリケーションが生まれる。

注意してほしいのだが、ソフトウェア技術者には、何かを修得することなどできないと言いたいわけではない。
たいていの人が漠然と考えているよりは、長い時間がかかると言いたいのだ。
平均的な学習曲線は、平坦に伸びていき、徐々に急激な傾きになっていく。
現代社会には、生涯をもってしても完全な知識など得ることができないような専門分野が多くある。

3.1 定理 3:できるだけ早く試作を作成する p31

「できるだけ早く」とは、本当に「できるだけ早く」ということだ。「大至急」だ。
アプリケーションの立案に少しの時間をかけ、あとはまっしぐらに進むだけだ。
命をかけてコードを書く。
端末が熱いうちにキーボードを打つ。
ナノ秒も無駄にする時間はない。

この考えは、多くの人が考える「正しい設計作法」と真っ向から対立している。
ほとんどの人は「アプリケーション設計を完全にしてからコーディングにかかれ」と教えられている。
「まず、機能仕様書を書かなくちゃ」と言う。
定期的なミーティングで方向性を確認する。
細部まではっきりさせた考えを設計仕様書に書く。
90パーセントの設計ができて始めてコンパイラを使う。

原理的には、もっともな指針に聞こえる。
しかしこの考え方は、試作というものの重要性を見過ごしている。
あるアイデアがものになりそうかどうか、目に見える現実的な場面でテストするには試作が一番だ。
試作以前のアイデアは、これはこう動くはずだという憶測の域を出ない。
この時点では、設計構想はほとんど理解されておらず、おそらく人によって解釈が異なっているだろう。
プロジェクトの前進には、全員の合意が必要だ。
試作は、具体的に目標を示すことで全員の合意を醸成する。

試作によって学ぶ 
試作が早ければ早いほど、製品のリリースは早まる。
試作によって何がうまくいくかが分かり、さらに重要なことに何がうまくいかないかが分かる。
一つの方針を選んだ以上、その方針の適否を早めに判断しなければならない。
前提の誤りを早期に発見し、わずかな被害ですませるのと、誤った前提のまま何ヵ月間も開発を進めて、
リリース日の3週間前になって不意打ちを食らうのと、どちらがよいかは言うまでもない。

早い試作はリスクを減らす p32

何か具体的なものがあれば、それを指し示し「こんなふうに動く」と言える。
信頼できるユーザーに見せてよい反応が得られれば、間違っていなかったことを確信できる。
それより、めちゃくちゃに叩かれることのほうが多いだろうが、それはそれでまた結構なことだ。
それによって、貴重な設計情報が得られるのだから。
製品の完成後に百万のユーザーから背中を向けられるよりも、少数から批判を受けるほうがはるかにいい。

正しい設計が一つしかないのに対し、間違った設計は何百通りもある。
早いうちから誤りを取り除く作業を始めておけば、それだけ早く高品質の最終製品にたどり着けるだろう。
調べれば調べるほど、計算できないアルゴリズム、合わないタイミング、インタフェースしないユーザーインタフェースなどが続々と見つかる。
これらの試行錯誤は、籾殻(もみがら)をふるいにかけ穀粒 (こくつぶ)だけを残す作業にも例えられる。

p44

UNIX開発者は、詳細な機能仕様書や設計仕様書について見方が異る。
目的は伝統的な方法論と同じだが、物事を進める順序が違う。

1. 短い機能仕様書を書く 
2. ソフトウェアを書く 
3. テストして書き直す。 満足できるまで、これを繰り返す 
4. 詳細なドキュメントを (必要なら) 書く

4.1 定理 4: 効率より移植性 p49

ソフトウェア開発にあたって、選択しなければいけないことは多い。
それはときに妥協の産物でもある。

美しいサブルーチンを書きたくても時間がないために、短い簡単なもので間に合わせなければならないことがある。
RAMが少ないために、書きたくても書けないアルゴリズムが出てくる。
大きなデータブロックの転送に適したネットワークプロトコルを使っているような状況では、
数多くの小さなデータパケットによって、ネットワークの帯域が占有されてしまわないようにしないといけない。
プログラマは、常にいくつかの妥協案の中からいずれかの方法を選択し、ときには矛盾する目的を達成しようとする。

中でも難問の一つが、移植性か効率かという選択だ。
これはひどく頭の痛い問題だ。
効率を選択すれば移植性に劣るコードができ、移植性を選択すればときに効率がいま一つのソフトウェアができあがる。
効率のよいソフトウェアは、マシン次第でいくらでも速く走る。
ハードウェアの性能を徹底的に活用し、移植性はしばしば犠牲になる。
グラフィックスアクセラレータ、キャッシュメモリ、特殊な浮動小数点命令などを活用するのだ。

スピード狂には効率のよいソフトウェアは実に魅力的だが、いくつものマシンアーキテクチャ上で動作することの価値を考えると、移植性重視になる。
その理由は技術的なものというよりは、経済的なものだ。
しかし、現在のコンピュータ環境において、ただ一つのアーキテクチャでしか動作しないソフトウェアでは、マーケットが非常に限られてしまう。

移植性を重視して作るということは、非効率な時代遅れのソフトウェアで我慢するということではない。
むしろその逆だ。

高い移植性を持ちながら同時に最適な性能を出すには、高度の技術的な洗練を必要とする。
よしんば当面、それだけの技術力がないとしても、より高速なハードウェアを待つことはできる。

プログラムを速くすることに時間をかけない p51

プログラムの速度に多少の不満があっても、現在のニーズが満たされていればそれでよしとする。
サブルーチンのチューニングとボトルネックの解消に時間を費やすにしても、
将来のハードウェアでの性能向上を常に視野に入れておかねばならない。

そのプログラム自身のためだけに、速くしようとする誘惑に抵抗することだ。
来年の新マシンは、すぐそこまで来ている。

多くのUNIXプログラマが冒す間違いの一つに、わずかな速度を求めてシェルスクリプトをC言語で書き直すというものがある。
それは、時間の無駄だ。

そのような時間は、ユーザーからの建設的な反応を得ることに費やしたほうがいい。
確かにシェルスクリプトでは十分な速度が引き出せないことがあるだろう。
しかしながら、絶対に速度が必要で、それにはC言語が必要だと考えている場合にも、もう一度考え直すべきだ。
特殊な例外はあっても、一般にスクリプトをC言語で書き直すことに大きな価値はない。

最も効率のよい方法は、ほとんどの場合移植性に欠ける p52

プログラムがハードウェアの持つ特殊機能を利用すると、プログラムは良くなり、移植性は悪くなる。
特殊機能を使うことで、プログラムの飛躍的に向上することもあるが、そのためには機器依存のコードを別に書かなければならない。

そしてその部分は、より高速なハードウェアによって既存のハードウェアが置き換えられるたびに書き直さねばならない。

ハードウェア依存コードの書き直しは、システムプログラマにとっては職の安定を意味しても、
雇用者側にとっては利益を増やすことにはあまりならない。

動かせないデータは、死んだデータだ。 p58

データを簡単に移動するためには、データには移植性を持たせねばならない。
データの移動への障害となるものは、故意でないにせよ、その設計からくるものにせよ、そのデータの潜在的な価値に限界を設けてしまう。
データが移動できない期間が長ければ長いほど、その最終的なデータの価値は小さくなる。
問題は、データの形式が移動先で使えなければ、それは変換しなければならないという点だ。
データ変換には時間がかかる。
データ変換に時間がかかればかかるほど、データの価値は減っていく。

独自技術症候群を避ける p71

これはとりわけ優れている組織でよく見られる。
あるグループが他グループのアプリケーションの価値を認めない、市販品を使うよりゼロからの開発を好む、
他人が書いたソフトウェアは、他人が書いたものだから使わない・・・このような症状が見られたら独自技術症候群を疑ったほうがいい。

一般に信じられているところとは反対に、独自技術症候群は創造性を伸ばさない。
他人の仕事を見て、自分のほうがうまくできると主張してみてもそれだけで創造性が増えるわけではない。
既存のアプリケーションをゼロから設計し直すことは模倣ではあっても創造とは言わない。
むしろこれを避けることで、新しいわくわくするような設計世界への扉が開かれる。
既存のルーチンを書き直さずにすむためにできた余裕で新しい機能を開発できる。

コードを他者が挺子として使うのを認める p73

ソフトウェア技術者は、ときに自分のソースコードを秘密にしておくことがある。
何か特別のもの、例えば世界を変えてしまう魔法を発明し、その秘密を自分だけが握っているという感覚だろうか。
ソースコードを明かしてしまうと、この高価な神秘の真珠を自分でコントロールできなくなるというような恐れが無意識のうちにあるのだろう。

まず第一に、ソフトウェアは魔法ではない。
ある程度論理的な頭脳を持った人なら誰でも書ける。
上手い下手はあるにせよ、すべてのソフトウェアは、結局のところ計算されたステートメントの集まりであり、
明確に定義されたある動作をハードウェアに行わせるにすぎない。

プログラマならソースコードなどなくても、プログラムを逆アセンブルすることもできる。
時間を費やすめんどうな作業だが、不可能ではない。

コントロールできなくなるのではないかという疑問についてはどうだろうか?
コンピュータの世界では一般に、ソースコードをコントロールする者がプログラムを「所有」すると信じられている。
それは、必ずしも間違いとはいえない。

ソースコードを保有している企業は、プログラムの修正を誰に許可するか、
誰にランタイムライセンスを認めるかなどをある程度コントロールできる。
しかし、残念ながら、ソフトウェアの寿命をコントロールしようとしても、
プログラム開発への投資を一時的に保護することができるだけで、ソフトウェアそのものを保護することはできない。

例えば、その機能や特徴を真似しょうとするクローンの出現を阻止することはできない。
普通、ある会社にとって投資する価値があると見えるアイデアは、競争相手にとっても投資する価値のあるアイデアだ。
他の会社が流行の波に乗り遅れまいとして、市場にクローンがあふれるのは時間の問題だ。
この場合、最も成功するソフトウェアはどれかと言えば、最も多くのコンピュータで使われているソフトウェアということになる。
この点で、秘密主義の企業は大きな不利を背負うことになる。

5.2 定理 7:シェルスクリプトを使うことで挺子の効果と移植性を高める p77

ソフトウェアの挺子を最大限利用しようと思えば、シェルスクリプトの効果的な使い方を学ばなければならない。
しかし、ここではそこまで立ち入らない。
すでに多くの本があるので、そちらを参照してほしい。
シェルスクリプトをどのように使うかについては、たいていそれで十分だろう。
その代わりにここではなぜ使うのかという理由に焦点を当てることにする。

この問題に入る前に、注意しておくことがある。
UNIXカーネルプログラマの中には、シェルスクリプトプログラマを軽視する人が少なくない。
シェルスクリプトを書くのは、「マッチョでない」というわけだ。
「熟練したシェルプログラマ」を「軽量のUNIX型」と呼ぶ向きもある。
シェルスクリプトはあまり頭痛を起こさないので、嫉妬しているのではないかと私は想像している。
あるいは、カーネルにはシェルスクリプトを使えないからだろうか。
いつの日か誰かが、シェルスクリプトも使えるようなUNIXカーネルを書いてくれないだろうか?
そうすれば、ソフトウェア挺子の効果というものが、このような人たちにもより良く理解されるだろうに。

シェルスクリプトについての議論を進めていくにつれて、私が「アンチC」であるかのような印象を受けるかもしれない。
つまり、プログラムは、Cのような移植性のある言語で書くべきものではないという論だ。
そうだとしたら、それはポイントを違えている。
C言語と、そこから生まれたC++言語は、現代の言語のうちで筆頭に挙げられるべき存在だ。
シェルでなく、Cでプログラムを書くことが妥当なケースも多々ある。
しかし、そのようなケースは、一般に考えられているほど多くはない。
C言語の人気がこれほど高いと、シェルを無視し、すべてのソフトウェアを「80年代のアセンブリ言語」で書こうという罠にはまりがちになる。
考えを完全に変えなくてもよいが、シェルという代替もあるのだということに気付いてほしい。

6.1 定理8: 過度の対話的インタフェースを避ける p90

拘束的ユーザーインタフェースを避ける理由について議論を始める前に、まずそれを定義しておこう。
拘束的ユーザーインタフェースとは、システムに存在するあるアプリケーションが、
最上位のコマンドインタープリタの範囲外にあって、ユーザーと対話するスタイルをいう。
いったん、 そのアプリケーションをコマンドインタープリタから起動すると、
そのアプリケーションが終了するまでコマンドインタープリタとの対話ができなくなる。
ユーザーはアプリケーションのユーザーインタフェースの内部に拘束され、拘束を解くための行動を起こさない限り、その拘束から逃れられない。

p111

上司は、顔をしかめた。
「なんてたくさんの木を殺しているんだ。 ちょっと来い」

オフィスに入ると、上司は真っ直ぐに端末に行き、UNIXの講義を始めた。
一生忘れられない講義だった。

「データを紙に印刷してしまったら、もうそれ以上操作できないんだぞ」と上司は言った。
紙に印刷されたデータは、並べ替えも、移動も、フィルタ処理も変形も、修正もできない。
少なくとも、コンピュータ上でやるように簡単にはできない。
瞬時に取り出せるように、巨大なディスクファームにアーカイブ保存することもできない。
キー一つで検索することもできない。
保護したい機密情報なのに暗号化もできない。

7.5 (5) 沈黙は金 p112

いや、マルチメディアはやめろ、と言っているのではない。
ここでは、いわゆる「ユーザーフレンドリ」なプログラムのことを取り上げたい。

一目瞭然なことをくどくどと説明したり、大の親友であるかのようにユーザーに話しかけたりするプログラムのことだ。
ユーザーに会話調で話しかけることがユーザーを助けることだと考えているプログラマが多すぎる。
UNIXは一般に「ドライ」で、ただ「事実」だけを伝える。
それ以上でも以下でもない。
UNIXコマンドの中には、入力データが与えられなかったり、出力するデータがなかったりしても、一見黙ったままのものが少なくない。
UNIXの初心者には、これがまごつく原因になることもある。
例えば、UNIX以外のシステムで、空っぽのディレクトリで以下のコマンドをタイプしたとする。
システムからユーザーに、ファイルが見つからなかったことを報告していることに注意してほしい。

データが何もないとき、コマンドが黙ったままでいることに何か利点があるのだろうか?
一つには、画面上には意味のあるデータだけが表示され、無意味とも思えるコメントがごちゃごちゃと並ばずにすむ。
ごちゃごちゃしたコメントの大海に囲まれていないことで、数滴のデータも探しやすくなる。

これで画面がすっきり保たれるが、もっと技術的な理由もある。
以前に議論したとおり、UNIXコマンドはフィルタとして機能し、UNIXのパイプ機構によって他のフィルタと結合される。

UNIXにおいては、言うべきことだけを言うのが重要だ。
それ以上でも、それ以下でもいけない。

p131

一つのことだけに専念すれば、小さなプログラムのまま、大きくて複雑な単体型プログラムになる危険を避けられる。
単体型プログラムは「スパゲッティコード」を含んでいることが多く、他のアプリケーションとの共同作業が苦手だ。
小さなプログラムは、今日とは違う明日があることを認識している。
今日完璧に見える機能でも、明日は不完全になり、場合によっては時代遅れになるかもしれない。
単体型プログラムは目前のすべての状況に対処しようとするが、
小さなプログラムはソフトウェアが進化することを率直に受け入れている。
ソフトウェアに完成はない。
ただリリースがあるだけだ。

p144

読者にはすでにお分かりのことだろう。
UNIXの考え方とは、常に将来を見据えながらオペレーティングシステムとソフトウェアの開発にアプローチすることだ。
そこでは、常に変化し続ける世界が想定されている。
将来は予測できない。
現在についてあらゆることを知っていても、その知識はまだまだ不完全なことは認めざるをえない。

ソフトウェアを開発するにせよ、子供たちのためにより良い世界を築くにせよ、将来はガラス越しにしか見えない。
いつか、すべての答えが分かる日が来るのかもしれないが、それまでは前進し続けなければならない。
いつか、すべての答えを知る時がやって来るのかもしれないが、
それまでは、一日ごとに「今日」が「昨日」になっていく日々を過ごしながら、
将来に適応し、前進しつづけなければならない。

UNIXの理念は、そういう将来に向かうアプローチの一つだ。
その本質は柔軟であり続けることだ。
嵐が何度やって来ても、風に揺れる木は折れることがない。