UNIX哲学とは、ソフトウェア開発に関する文化的な規範と哲学的アプローチのまとまりであり、UNIX OSの先駆的な開発者たちの経験に基づいている。パイプの発明者でありUNIX創始者の一人でもあるマキルロイは、この哲学を以下のように要約した。この哲学はしばしば、「一つのことを、うまくやれ」とさらに厳格に要約される。3つの教義のうち第3のものだけがUNIX特有であるが、UNIXの開発者はしばしば3つの教義すべてを他の開発者よりも重要視する。（注意: これは直接にはUNIX哲学ではない。強い結びつきのあるC言語についての記述ではあるが。現在英語版のこの記事には、この節に対応する節はない）ロブ・パイクは "Notes on Programming in C" の中で、以下のようなルールをプログラミングの格言として提案している。これはまたUNIX哲学のポイントとも共通点がある。Rule 1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is.Rule 2. Measure. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest.Rule 3. Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don't get fancy. (Even if n does get big, use Rule 2 first.) For example, binary trees are always faster than splay trees for workaday problems.Rule 4. Fancy algorithms are buggier than simple ones, and they're much harder to implement. Use simple algorithms as well as simple data structures.Rule 5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self­evident. Data structures, not algorithms, are central to programming.Rule 6. There is no Rule 6.パイクのルール1と2は、ドナルド・クヌースが述べた格言「早すぎる最適化は諸悪の根源である」を言い換えたものである（最適化 (情報工学)#最適化する時期も参照）。ケン・トンプソンはパイクのルール3と4を「疑いがあるときは総当たり（brute force）を使え」と言い換えている。ルール3と4はデザイン哲学KISSの例である。ルール5はフレッド・ブルックスが以前に「人月の神話」の中で述べている。ジョン・ベントレーの " は同じデザイン原則について述べた章を含んでいる。ルール5はしばしば「スマートなデータを使うつまらないコードを書け」と短縮され、また「データ構造が十分に良いものなら、それを扱うアルゴリズムは平凡であるべきだ」というガイドラインの実例でもある。ルール6はモンティ・パイソンの「ブルース・スケッチ」を愉快に参照しているだけのものだ。Cの文字列では最後の1バイトがヌル文字であり、したがってその文字列の長さを示すことになる。1994年、マイク・ガンカーズ（X Window System開発チームの一員）は、UNIXで得た経験と、同僚プログラマーやUNIXに依存する他分野の人々との議論を活かし、以下の9つの至上命令に集約される「UNIX哲学」を創出した。以下の重要性が相対的に低い教義は、UNIX哲学の一部として普遍的に合意されるものではなく、場合によっては現在も激しく議論されているものである（例えばモノリシックカーネルとマイクロカーネルのように）。リチャード・P・ガブリエルは、UNIXの重要な優位性のひとつは彼が「より悪いことは、より良いことだ」（"Worse is better"）という用語に込めるデザイン哲学を体現しているところにあると述べている。「より悪いことは、より良いことだ」式のデザイン・スタイルでは、インターフェースと実装の両面がシンプルであることが、システムにおける他のいかなる特性よりも重視される――正確さ、堅牢さ、完全さよりも、である。ガブリエルは、このデザイン・スタイルが発展のための重要な利点を持っていると論じているが、一方でいくつかの結果の質について疑問を抱いてもいる。例えば、黎明期のUNIXにおいて、プロセスはカーネル・システムコールをすべてユーザスタック上で実行した。もしカーネル内で長期間のI/Oやsleepによってプロセスがブロックしているときに（例えばcodice_1のように）、そのプロセスにシグナルが通知されたら、何が行われるのだろうか？　シグナルはI/Oが完了するまでの間（どれくらいかわからないが、おそらく長い間）遅延されるのか？　プロセスがカーネルモードで動いている場合、シグナル・ハンドラは実行され得ず、スタックには繊細なカーネル・データが残ったままである。カーネルはシステムコールを棄却（バックアウト）し、応答と再始動に備えて保管し、成功裏にシグナルハンドラを完了することを引き受けるべきなのか？このようなケースでは、ケン・トンプソンとデニス・リッチーは完全性よりもシンプルさを好む。UNIXシステムは機会ごとにシステムコールから素早く復帰し、何もしなかったことを知らせるエラー通知（「"Interrupted System Call" システムコールに割り込みが発生」）を行う。すなわちエラー番号4（EINTR）である。もちろん、このような呼び出しはシグナルハンドラを呼び出すために中断されている。こうしたことは、長期間実行されうる一群のシステムコール（つまりcodice_2、codice_3、codice_4、codice_5等）において起こり得る。利点としては、この仕組みはI/Oシステムを何倍もデザインしやすく、理解しやすいものにしている。圧倒的多数のプログラムは影響を受けない。なぜならこうしたプログラムはSIGINT/^C以外のシグナルを扱わず、経験もしないし、SIGINTが発せられたときには正確に終了（die）するからである。それ以外の少数のプログラム（ジョブ制御のキー入力を受け付けるシェルやテキストエディタのようなもの）のためには、システムコールの小さなラッパー（wrapper）を追加することができ、EINTRエラーが起こったらすぐにシステムコールを再試行できるのである。問題はシンプルな方法で解決される。（現在のUnixクローンでは、カーネルコードがユーザスタックで実行されたりしないし、I/O中のシグナルについて、このようなふるまいであったのは、初期のUNIXやSystemV（あるいは初期のLinux）においてのことである。4.3以降のBSDや現在のLinuxでは、全くI/Oが進行していない状態でシグナルが入った場合、シグナルの処理が終わった後、中断されたI/Oが再開される）エリック・S・レイモンドは著書『The Art of UNIX Programming』の中で、UNIX哲学を "Keep it Simple, Stupid" （KISS原則、「シンプルでつまらないものに保て」）という、広く使われている工学哲学として要約した。そしてレイモンドは、彼がいかにこの総体的な哲学がUNIXの文化的規範として適用されていると信じているか述べている。だが以下のルールを深刻に違反した例が実際のUNIXの実践において簡単に発見できるのも驚くべきことではない。これら規範の多くはUNIXコミュニティの外で受け入れられている――最初にUNIXが採用したときはそうでなかったとしても、後にそうなった。また、多くはUNIXコミュニティ独特のものではなく、UNIXコミュニティから生じたわけでもない。にもかかわらず、熟練のUNIXプログラマーはこれらの考え方を組み合わせたものをUNIXスタイルの基礎として受け入れる傾向がある。GNUプロジェクトによる標準的なUNIXプログラムの代替（diffやfind等）が「Unix哲学」に従うものであるのか、あるいはそれを誤解しているのかは議論の分かれるところである。おそらく、UNIXに古くから関わる人々のうちの少なくともいくらかは後者を主張するであろう。なぜならGNUプロジェクトのツール群はしばしばUNIXと同等のものよりも十分に大きく、また機能も豊富だからである（GNUはコーディング標準において、いくつかの点でUNIXと同じにしないことを薦めている）。GNU以前に1983年にはすでにロブ・パイクによる、Unixの基本的なツールにおいてBSDによって拡張された機能のうちのいくつか（代表例として挙げられたのは、cat に制御コードを文字に変換して可視化させる -v ）の仕様が、Unix的でないとした批判がある。確かにUnix哲学に従えば、cat -v の機能は独立したフィルタで果たされるべきであり、本来は「連結」コマンドである cat が単にストリームを読んで書くだけの目的に流用されることが多いとはいえ、それに加えてあれこれと機能を持つべきではない。しかし、同様にして批判された別の例である、ls コマンドが出力を表示される幅に合わせて整形する機能などは十分に便利ではあり、Unix哲学に従って column コマンドをパイプで繋げるのはどう考えてもかったるい。そういったわけで、現代では議論されることはあまり見られなくなったものの、普段Linux等を使っている際に当然とされていることが本当に当然なのか、考えさせられる論点がある。

出典:wikipedia