UNIX哲学
Salusが『A Quarter-Century of Unix』(1994年)にまとめている:
一つのことをうまくやるプログラムを書く
連携するプログラムを書く
普遍的なインターフェースであるテキストストリームを扱うプログラムを書く
1974年のUnix論文で、ケン・トンプソンとデニス・リッチーはUNIXの設計で以下を考慮したと述べている:
プログラムを書いたり、テストしたり、実行したりするのが簡単に行えるようシステムを設計した
当初のバージョンでは1人のユーザーしかサポートしていなかったものの、システムを対話的に使用できるようにした
適切に設計された対話型システムは、「バッチ処理」システムよりもはるかに生産的で満足のいくものであると信じている
サイズの制約は経済性だけでなく、かえって設計をエレガントにする方向に働いた
すべてのUnixソフトウェアはUnixの下で保守されている
パイプの発明者でありUNIX創始者の一人でもあるマキルロイはこの哲学を以下のように要約した:
この哲学は「一つのことを、うまくやれ」とさらに要約されることがある。このうち3つめだけがUNIXに特有である。
開発者は大きなプログラムを書くことを避けるべきである。これは開発時間の過剰投資を防ぐことが目的である。膨大な作業の数々を破棄したくないというプログラム所有者の気持ちが原因で起こる。小さなプログラムは、最適化やメンテナンスが容易であるだけでなく、廃棄する事も容易である。
1978年のBell System Technical Journalにダグラス・マキルロイ他によって記載されている:
それぞれのプログラムが1つのことをうまくこなすように。新しい仕事をするために、新しい「機能」を追加して古いプログラムを複雑にするのではなく、新しいプログラムを構築する。
すべてのプログラムの出力が、まだ見ぬ別のプログラムの入力になること。出力に余計な情報を入れないように。厳密に列挙された入力形式やバイナリ形式は避ける。インタラクティブな入力にこだわらない
ソフトウェアはもちろんOSであっても、早期に、理想としては数週間以内に試せるよう設計・構築する。不器用な部分は躊躇なく捨てて作り直すように
回り道をしても、使い終わった後に捨てることになっても、プログラミングの作業を軽減するためには、お手伝いさんではなくツールを使う
その後、en:Peter H.
他のプログラムと接続できるようプログラムをデザインせよ。
開発者は他のプログラムと簡単に通信できるプログラムを書くべきである。開発者がプロジェクトを、過度に複雑な一枚岩のプログラムではなく、小さくてシンプルなプログラムに分解することを目的とする。
失敗しなければならないときは、騒がしく、かつできるだけ早く失敗せよ。
開発者は故障の原因が特定しやすく、診断しやすい、つまり「音を立てて故障する」プログラムを設計する必要があります。プログラムからの不正な出力が入力となり、他のコードの出力が検出されずに破損することを防ぐことを目的とする。