UNIX哲学

出典: フリー百科事典『ウィキペディア（Wikipedia）』

「UNIX哲学」とは、ソフトウェア開発に関する文化的な規範と哲学的アプローチのまとまりであり、UNIX OSの先駆的な開発者たちの経験に基づいている。

目次

[編集] マキルロイ: UNIXの四半世紀

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

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

– M. D. マキルロイ, UNIXの四半世紀

この哲学はしばしば、「一つのことを、うまくやれ」とさらに厳格に要約される。

3つの教義のうち第3のものだけがUNIX特有であるが、UNIXの開発者はしばしば3つの教義すべてを他の開発者よりも重要視する。

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

ロブ・パイクはNotes on Programming in C[1]の中で、以下のようなルールをプログラミングの格言として提案している。これはまたUNIX哲学のポイントとも共通点がある。

  • ルール1: プログラムがどこで時間を消費することになるか知ることはできない。ボトルネックは驚くべき箇所で起こるものだから、どこがボトルネックなのかをはっきりさせるまでは、推測を行ったり、スピードハックをしてはならない。
  • ルール2: 計測すべし。計測するまでは速度のための調整をしてはならない。コードの一部が残りを圧倒しないのであれば、なおさらである。
  • ルール3: ファンシーなアルゴリズムはnが小さいときには遅く、nはしばしば小さい。ファンシーなアルゴリズムは大きな定数を持っている。nが頻繁に大きくなることがわかっていないなら、ファンシーにしてはいけない（nが大きくなるときでさえ、ルール2が最初に適用される）。
  • ルール4: ファンシーなアルゴリズムはシンプルなそれよりバグを含みやすく、実装するのも難しい。シンプルなアルゴリズムとシンプルなデータ構造を使うべし。
  • ルール5: データはすべてを決定づける。もし正しいデータ構造を選びものごとをうまく構成すれば、アルゴリズムはほとんどいつも自明のものになるだろう。プログラミングの中心は、アルゴリズムではなくデータ構造にある。
  • ルール6: ルール6は存在しない。

パイクのルール1と2は、アントニー・ホーアの格言「早すぎる最適化は諸悪の根源である」を言い換えたものである。ケン・トンプソンはパイクのルール3と4を「疑いがあるときは総当たり（brute force）を使え」と言い換えている。ルール3と4はデザイン哲学KISSの例である。ルール5はフレッド・ブルックスが以前にThe Mythical Man-Monthの中で述べている。ジョン・ベントレーのProgramming Pearlsは同じデザイン原則について述べた章を含んでいる。ルール5はしばしば「スマートなデータを使うつまらないコードを書け」と短縮され、また「データ構造が十分に良いものなら、それを扱うアルゴリズムは平凡であるべきだ」というガイドラインの実例でもある。ルール6はモンティ・パイソンの「ブルース・スケッチ」を愉快に参照しているだけのものだ。Cの文字列では最後の1バイトがヌル文字であり、したがってその文字列の長さを示すことになる。

[編集] ガンカーズ: UNIXの哲学

1994年、マイク・ガンカーズ（X Window System開発チームの一員）は、UNIXで得た経験と、同僚プログラマーやUNIXに依存する他分野の人々との議論を活かし、以下の9つの至上命題に集約される「UNIX哲学」を創出した。

  1. 小さいものは美しい。
  2. 各プログラムが一つのことをうまくやるようにせよ。
  3. できる限り原型（プロトタイプ）を作れ。
  4. 効率よりも移植しやすさを選べ。
  5. 単純なテキストファイルにデータを格納せよ。
  6. ソフトウェアの効率をきみの優位さとして利用せよ。
  7. 効率と移植性を高めるためにシェルスクリプトを利用せよ。
  8. 束縛するインターフェースは作るな。
  9. 全てのプログラムはフィルタとして振る舞うようにせよ。

以下の重要性が相対的に低い教義は、UNIX哲学の一部として普遍的に合意されるものではなく、場合によっては現在も激しく議論されているものである（例えばモノリシックカーネルとマイクロカーネルのように）。

  1. ユーザが環境を設定できるようにせよ。
  2. OSのカーネルは小さく軽量にせよ。
  3. 小文字の短い名前を使え。
  4. ツリー構造を保て。
  5. 沈黙は金なり。
  6. 並行性を考えよ。
  7. 部分の集積は全体よりも大きい。
  8. 90パーセントの解決を模索せよ。
  9. より悪いことは、より良いことだ。
  10. 階層的に考えよ。

[編集] より悪いことは、より良いことだ（Worse is better）

リチャード・P・ガブリエルは、UNIXの重要な優位性のひとつは彼が「より悪いことは、より良いことだ」（"Worse is better"）という用語に込めるデザイン哲学を体現しているところにあると述べている。「より悪いことは、より良いことだ」式のデザイン・スタイルでは、インターフェースと実装の両面がシンプルであることが、システムにおける他のいかなる特性よりも重視される――正確さ、堅牢さ、完全さよりも、である。ガブリエルは、このデザイン・スタイルが発展のための重要な利点を持っていると論じているが、一方でいくつかの結果の質について疑問を抱いてもいる。

例えば、黎明期のUNIXはモノリシックカーネルであった（つまりユーザプロセスはカーネル・システムコールをすべてユーザスタック上で実行した）。もしカーネル内で長期間のI/Oによってシグナルがブロックされているときにそのシグナルがプロセスに通知されたら（例えばsleep(10*60)のように）、何が行われるのだろうか？　シグナルはI/Oが完了するまでの間（どれくらいかわからないが、おそらく長い間）遅延されるのか？　プロセスがカーネルモードで動いている場合、シグナル・ハンドラは実行され得ず、スタックには繊細なカーネル・データが残ったままである。カーネルはシステムコールを棄却（バックアウト）し、応答と再始動に備えて保管し、成功裏にシグナルハンドラを完了することを引き受けるべきなのか？

このようなケースでは、ケン・トンプソンとデニス・リッチーは完全性よりもシンプルさを好む。UNIXシステムは機会ごとにシステムコールから素早く復帰し、何もしなかったことを知らせるエラー通知（「Interrupted System Call システムコールに割り込みが発生」）を行う。今日のシステムではエラー番号4（EINTR）である。もちろん、このような呼び出しはシグナルハンドラを呼び出すために中断されている。こうしたことは、長期間実行される一握りのシステムコール（つまりread()、write()、open()、select()等）のためだけに起こり得る。利点としては、この仕組みはI/Oシステムを何倍もデザインしやすく、理解しやすいものにしている。圧倒的多数のプログラムは影響を受けない。なぜならこうしたプログラムはSIGINT/^C以外のシグナルを扱わず、経験もしないし、SIGINTが発せられたときには正確に終了（die）するからである。それ以外の少数のプログラム（ジョブ制御のキー入力を受け付けるシェルやテキストエディタのようなもの）のためには、システムコールの小さなラッパー（wrapper）を追加することができ、EINTRエラーが起こったらすぐにシステムコールを再試行できるのである。問題はシンプルな方法で解決される。

[編集] レイモンド: UNIXプログラミングの技法

エリック・S・レイモンドは著書『The Art of UNIX Programming』[2]の中で、UNIX哲学を "Keep it Simple, Stupid" （KISS原則、「シンプルでつまらないものに保て」）という、広く使われている工学哲学として要約した。そしてレイモンドは、彼がいかにこの総体的な哲学がUNIXの文化的規範として適用されていると信じているか述べている。だが以下のルールを深刻に違反した例が実際のUNIXの実践において簡単に発見できるのも驚くべきことではない。

モジュール性のルール
クリーンなインターフェースで接続されるシンプルなパーツを書け。
明瞭さのルール
明瞭さは独創性よりも良い。
合成のルール
他のプログラムと接続できるようプログラムをデザインせよ。
分割のルール
ポリシーをメカニズムから分離せよ。インターフェースをエンジンから分離せよ。
シンプルさのルール
シンプルさを求めてデザインせよ。複雑にしなければならない場合に限り、複雑さを加えよ。
倹約のルール
他に方法がないことが実験により明らかである場合に限り、大きいプログラムを書け。
透明性のルール
透明性を求めてデザインせよ。調査とデバッグが簡単になる。
頑丈さのルール
頑丈さは透明性とシンプルさから生まれる。
代表のルール
知識をデータに織り込め。するとプログラムのロジックをつまらなくて頑丈なものにできる。
最小限の驚きのルール
インターフェースデザインにおいては、常に驚きが最小限であるようにせよ。
沈黙のルール
プログラムが人を驚かせるような何事かを持っていない状態ならば、そのプログラムは何も言うべきではない。
修復のルール
失敗しなければならないときは、騒がしく、かつできるだけ早く失敗せよ。
経済のルール
プログラマの時間は貴重である。プログラマの時間をコンピュータの時間より優先して節約せよ。
生成のルール
hand-hacking[3]は避けよ。プログラムを書けるときに、プログラムを書くためにプログラムを書け。
最適化のルール
洗練させる前に原型（プロトタイプ）を作れ。最適化する前に原型が動くようにせよ。
多様性のルール
あらゆる「ただ一つの本当の方法」という主張は信じるな。
拡張性のルール
未来に向けてデザインせよ。未来は思ったよりもすぐにやってくる。

これら規範の多くはUNIXコミュニティの外で受け入れられている――最初にUNIXが採用したときはそうでなかったとしても、後にそうなった。また、多くはUNIXコミュニティ独特のものではなく、UNIXコミュニティから生じたわけでもない。にもかかわらず、熟練のUNIXプログラマーはこれらの考え方を組み合わせたものをUNIXスタイルの基礎として受け入れる傾向がある。

[編集] 論争

フリーソフトウェア財団による標準的なUNIXプログラムのGNU互換製品（diffやfind等）が「UNIX哲学」に従うものであるのか、あるいはそれを誤解しているのかは議論の分かれるところである。おそらく、UNIXに古くから関わる人々のうちの少なくともいくらかは後者を主張するであろう。なぜならGNUのツール群はしばしばUNIXと同等のものよりも十分に大きく、また機能も豊富だからである。

1983年にはすでにロブ・パイクが、cat[1]のような基礎的なUNIXツールの機能をBSDが拡張したことに対して批判する論文を発表している。この傾向は、GNUや商業版のUNIX互換製品の登場とともに、より重大な意味を持つことになった。またこのことは、呼び出し方によって変わる数多くの機能を提供するプログラム全般に共通している（例えば、ファイルが何と呼ばれているかによってそのファイルを圧縮したり解凍したりするプログラムがある。極端な例ではLinuxアプリケーションのBusyBox。これは一般的コマンドのほとんどを一つのバイナリに集約したものである）。

[編集] 引用

  • 「UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである」 - デニス・リッチー
  • 「UNIXはユーザが愚かなことをするのを止めるために作られたのではない。小器用なことをするのも防いでくれるのだ」 - ダグ・グウィン
  • 「UNIXはユーザーフレンドリーだ。しかも親密になるユーザをごちゃまぜにすることがない」（It just isn't promiscuous about which users it's friendly with）」 - スティーブン・キング
  • 「UNIXを理解しない人々は、それを不十分に再発明することになるだろう」 - ヘンリー・スペンサー

[編集] 関連項目

[編集] 参照

[編集] 脚註

  1. ^ Pike, Rob (1989-02-21). "Notes on Programming in C". 2008年11月21日 閲覧。
  2. ^ Addison-Wesley刊 ISBN 978-0-13-142901-7、アスキー刊日本語版 ISBN 978-4-7561-4948-0
  3. ^ http://www.catb.org/jargon/html/H/hand-hacking.html

[編集] 外部リンク

"http://ja.wikipedia.org/wiki/UNIX%E5%93%B2%E5%AD%A6" より作成