「UNIX哲学」の版間の差分

https://ja.wikipedia.org/wiki/Help:%E7%AE%87%E6%9D%A1%E6%9B%B8%E3%81%8D#%E8%A6%8B%E6%A0%84%E3%81%88%E3%81%AB%E3%81%93%E3%81%A0%E3%82%8F%E3%82%89%E3%81%AA%E3%81%84
(https://ja.wikipedia.org/wiki/Help:%E7%AE%87%E6%9D%A1%E6%9B%B8%E3%81%8D#%E8%A6%8B%E6%A0%84%E3%81%88%E3%81%AB%E3%81%93%E3%81%A0%E3%82%8F%E3%82%89%E3%81%AA%E3%81%84)
 
*商用UNIXには大規模で多機能なアプリケーションソフトウエアーが含まれている場合がある
 
すなわち、"UNIX哲学"が、一貫したものとして当初から存在し続けているわけではなく、UNIXに関わる全ての人に共通認識として受け入れられているわけでもなく、UNIXの置かれている現や過去の状況を必ずしも的確に表現し得ているわけでもない。また、そこで表現されている手法の妥当性や有効性が、普遍的に立証されているわけでもない。
 
ある意味では、"UNIX哲学"とは、UNIXに関心を示す人々のうちの一部が抱く、希望や願望あるいは理想を表明したものにすぎない。
[[ロブ・パイク]]は ''Notes on Programming in C'' <ref>{{Cite web|url=http://www.lysator.liu.se/c/pikestyle.html|first=Rob|last=Pike|title=Notes on Programming in C|date=1989-02-21 |accessdate=2008年11月21日 }}</ref>の中で、以下のようなルールをプログラミングの格言として提案している。これはまたUNIX哲学のポイントとも共通点がある。
 
*ルール1: プログラムがどこで時間を消費することになるか知ることはできない。ボトルネックは驚くべき箇所で起こるものである。したがって、どこがボトルネックなのかをはっきりさせるまでは、推測を行ったり、スピードハックをしてはならない。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.
*ルール2: 計測すべし。計測するまでは速度のための調整をしてはならない。コードの一部が残りを圧倒しないのであれば、なおさらである。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 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.
*ルール3: 凝った(Fancy)[[アルゴリズム]]は<math>n</math>が小さいときには遅く、<math>n</math>はしばしば小さい。凝ったアルゴリズムは大きな定数を持っている<ref>訳註:凝ったアルゴリズムは、それ自身がすでに大きなコストであるということ。</ref>。<math>n</math>が頻繁に大きくなることがわかっていないなら、凝ってはいけない(<math>n</math>が大きくなるときでさえ、ルール2が最初に適用される)。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.
*ルール2: 計測すべし。計測するまでは速度のための調整をしてはならない。コードの一部が残りを圧倒しないのであれば、なおさらである。
*ルール4: 凝ったアルゴリズムはシンプルなそれよりバグを含みやすく、実装するのも難しい。シンプルなアルゴリズムとシンプルな[[データ構造]]を使うべし。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 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.
*ルール5: データはすべてを決定づける。もし、正しいデータ構造を選び、ものごとをうまく構成すれば、アルゴリズムはほとんどいつも自明のものになるだろう。プログラミングの中心は、アルゴリズムではなくデータ構造にある。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.
*ルール3: 凝った(Fancy)[[アルゴリズム]]は<math>n</math>が小さいときには遅く、<math>n</math>はしばしば小さい。凝ったアルゴリズムは大きな定数を持っている<ref>訳註:凝ったアルゴリズムは、それ自身がすでに大きなコストであるということ。</ref>。<math>n</math>が頻繁に大きくなることがわかっていないなら、凝ってはいけない(<math>n</math>が大きくなるときでさえ、ルール2が最初に適用される)。
*ルール6: ルール6は存在しない。Rule 6. There is no Rule 6.
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.
*ルール4: 凝ったアルゴリズムはシンプルなそれよりバグを含みやすく、実装するのも難しい。シンプルなアルゴリズムとシンプルな[[データ構造]]を使うべし。
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.
*ルール5: データはすべてを決定づける。もし、正しいデータ構造を選び、ものごとをうまく構成すれば、アルゴリズムはほとんどいつも自明のものになるだろう。プログラミングの中心は、アルゴリズムではなくデータ構造にある。
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.
*ルール6: ルール6は存在しない。
Rule 6. There is no Rule 6.
 
パイクのルール1と2は、[[ドナルド・クヌース]]が述べた格言「早すぎる最適化は諸悪の根源である」を言い換えたものである([[最適化 (情報工学)#最適化する時期]]も参照)。[[ケン・トンプソン]]はパイクのルール3と4を「疑いがあるときは[[力まかせ探索|総当たり]](brute force)を使え」と言い換えている。ルール3と4はデザイン哲学[[KISS原則|KISS]]の例である。ルール5は[[フレデリック・ブルックス|フレッド・ブルックス]]が以前に「[[人月の神話]]」の中で述べている。ジョン・ベントレーの ''[[:en:Programming Pearls|Programming Pearls]]'' は同じデザイン原則について述べた章を含んでいる。ルール5はしばしば「スマートなデータを使うつまらないコードを書け」と短縮され、また「データ構造が十分に良いものなら、それを扱うアルゴリズムは平凡であるべきだ」というガイドラインの実例でもある。ルール6は[[モンティ・パイソン]]の「ブルース・スケッチ」を愉快に参照しているだけのものだ。Cの文字列では最後の1バイトが[[ヌル文字]]であり、したがってその文字列の長さを示すことになる{{要出典|date=2020年1月}}
 
==ガンカーズ: UNIXの哲学==
 
==レイモンド: UNIXプログラミングの技法==
[[エリック・レイモンド|エリック・S・レイモンド]]は著書『The Art of UNIX Programming』<ref>Addison-Wesley刊 ISBN 978-0-13-142901-7、アスキー刊日本語版 ISBN 978-4-7561-4948-0</ref>の中で、UNIX哲学を "Keep it Simple, Stupid" ([[KISS原則]]、「シンプルでつまらないものに保て」)という、広く使われている工学哲学として要約した。そしてレイモンドは、彼がいかにこの総体的な哲学がUNIXの文化的規範として適用されていると信じているか述べている。だが以下のルール深刻に違反した例が実際のUNIXの実践において簡単に発見できるのも驚くべきことではない。
 
;[[モジュール]]性のルール
[[GNUプロジェクト]]による標準的なUNIXプログラムの代替(diffやfind等)が「Unix哲学」に従うものであるのか、あるいはそれを誤解しているのかは議論の分かれるところである。おそらく、UNIXに古くから関わる人々のうちの少なくともいくらかは後者を主張するであろう。なぜならGNUプロジェクトのツール群はしばしばUNIXと同等のものよりも十分に大きく、また機能も豊富だからである([[GNU]]はコーディング標準において、いくつかの点でUNIXと同じにしないことを薦めている)。
 
GNU以前に1983年にはすでにロブ・パイクによる、Unixの基本的なツールにおいてBSDによって拡張された機能のうちのいくつか(代表例として挙げられたのは、cat に制御コードを文字に変換して可視化させる -v )の仕様が、Unix的でないとした批判がある<ref>http://harmful.cat-v.org/cat-v/</ref>。確かにUnix哲学に従えば、cat -v の機能は独立したフィルタで果たされるべきであり、本来は「連結」コマンドである cat が単にストリームを読んで書くだけの目的に流用されることが多いとはいえ、それに加えてあれこれと機能を持つべきではない{{要校閲|date=2020年1月}}
 
しかし、同様にして批判された別の例である、ls コマンドが出力を表示される幅に合わせて整形する機能などは十分に便利ではあり、Unix哲学に従って column コマンドをパイプで繋げるのはどう考えてもかったる煩わし 。そういったわけで、現代では議論されることはあまり見られなくなったものの、普段Linux等を使っている際に当然とされていることが本当に当然なのか、考えさせられる論点がある{{要出典|date=2020年1月}}。<!--同一のバイナリが違う名前で起動されると働きが異なる件について記述がありましたが、カットしました。多分、ls コマンドの議論に出力先により結果が違うこと(パイプが出力先だと整形が起きないこと)というのがあるので、そこからの連想だったのかもしれませんが、違う名前で起動されるコマンドというのは少し話が違ってくるはずです-->
 
==引用==