UNIX哲学

ウィキペディア

UNIX哲学

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2025/04/04 07:23 UTC 版)

この項目「UNIX哲学」は途中まで翻訳されたものです。（原文：en:Unix_philosophy　（本文に英文が移されています）） 翻訳作業に協力して下さる方を求めています。ノートページや履歴、翻訳のガイドラインも参照してください。要約欄への翻訳情報の記入をお忘れなく。（2020年6月）

UNIX哲学（ユニックスてつがく、英: The UNIX Philosophy）とは、ソフトウェア開発の文化的な規範と哲学のまとまりであり、UNIX OS開発者たちの経験に基づくものとされている。その内容は発言者によって異なり、以下の点に留意が必要である：

• UNIXが開発された1971年から10年以上後の発言が大半である
• 発言者にはUNIX開発と関わり合いが希薄な人物も含まれている
• UNIXを生み出したケン・トンプソンやデニス・リッチーは"哲学"(philosophy)という表現をしていない
• 哲学に反して商用UNIXには大規模で多機能なソフトウェアが含まれている場合がある

すなわち、この哲学は当初から一貫して存在していたわけではなく、UNIXに関わる全ての人の共通認識でもなく、UNIXの現在や過去の状況を必ずしも的確に表現しているわけでもない。妥当性や有効性が普遍的に立証されているわけでもない。UNIXに関心を示す人々の一部の希望、願望、理想にすぎない。

起源

1978年のBell System Technical Journal^[1]にダグラス・マキルロイ^[2]他によって記載されている：

1. それぞれのプログラムが1つのことをうまくこなすように。新しい仕事をするために、新しい「機能」を追加して古いプログラムを複雑にするのではなく、新しいプログラムを構築する。
2. すべてのプログラムの出力が、まだ見ぬ別のプログラムの入力になること。出力に余計な情報を入れないように。厳密に列挙された入力形式やバイナリ形式は避ける。インタラクティブな入力にこだわらない
3. ソフトウェアはもちろんOSであっても、早期に、理想としては数週間以内に試せるよう設計・構築する。不器用な部分は躊躇なく捨てて作り直すように
4. 回り道をしても、使い終わった後に捨てることになっても、プログラミングの作業を軽減するためには、お手伝いさんではなくツールを使う

その後、en:Peter H. Salusが『A Quarter-Century of Unix』（1994年）^[2]にまとめている：

• 一つのことをうまくやるプログラムを書く
• 連携するプログラムを書く
• 普遍的なインターフェースであるテキストストリームを扱うプログラムを書く

1974年のUnix論文^[3]で、ケン・トンプソンとデニス・リッチーはUNIXの設計で以下を考慮したと述べている：

• プログラムを書いたり、テストしたり、実行したりするのが簡単に行えるようシステムを設計した
• 当初のバージョンでは1人のユーザーしかサポートしていなかったものの、システムを対話的に使用できるようにした
• 適切に設計された対話型システムは、「バッチ処理」システムよりもはるかに生産的で満足のいくものであると信じている
• サイズの制約は経済性だけでなく、かえって設計をエレガントにする方向に働いた
• すべてのUnixソフトウェアはUnixの下で保守されている

マキルロイ: UNIXの四半世紀

パイプの発明者でありUNIX創始者の一人でもあるマキルロイはこの哲学を以下のように要約した：

これがUNIXの哲学である。
一つのことを行い、またそれをうまくやるプログラムを書け。
協調して動くプログラムを書け。
標準入出力（テキスト・ストリーム）を扱うプログラムを書け。標準入出力は普遍的インターフェースなのだ。 — ダグラス・マキルロイ、UNIXの四半世紀

この哲学は「一つのことを、うまくやれ」とさらに要約されることがある。このうち3つめだけがUNIXに特有である。

パイク: Cプログラミングに関する覚え書き

（注意: これは直接にはUNIX哲学ではない。強い結びつきのあるC言語の記述ではある）

ロブ・パイクは Notes on Programming in C ^[4]で以下をプログラミングの格言として提案している。UNIX哲学と共通点がある。

• ルール1: プログラムがどこで時間を消費することになるか知ることはできない。ボトルネックは驚くべき箇所で起こるものである。したがって、どこがボトルネックなのかをはっきりさせるまでは、推測を行ったり、スピードハックをしてはならない。
• ルール2: 計測すべし。計測するまでは速度のための調整をしてはならない。コードの一部が残りを圧倒しないのであれば、なおさらである。
• ルール3: 凝った(Fancy)アルゴリズムは${\displaystyle n}$