【InfoCLIP】Unix哲学について

UNIX哲学 - Wikipedia
UNIX哲学 "Keep it Simple, Stupid" （KISS原則、「シンプルでつまらないものに保て」）

原則多すぎだろ。

ロブ・パイクは Notes on Programming in C [1]の中で、以下のようなルールをプログラミングの格言として提案している。

これはまた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.

ルール3: ファンシーなアルゴリズムはnが小さいときには遅く、nはしばしば小さい。ファンシーなアルゴリズムは大きな定数を持っている。nが頻繁に大きくなることがわかっていないなら、ファンシーにしてはいけない（nが大きくなるときでさえ、ルール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.

ルール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.

小さいものは美しい。
Small is beautiful.

各プログラムが一つのことをうまくやるようにせよ。
Make each program do one thing well.

できる限り原型（プロトタイプ）を作れ。
Build a prototype as soon as possible.

効率よりも移植しやすさを選べ。
Choose portability over efficiency.

単純なテキストファイルにデータを格納せよ。
Store data in flat text files.

ソフトウェアの効率をきみの優位さとして利用せよ。
Use software leverage to your advantage.

効率と移植性を高めるためにシェルスクリプトを利用せよ。
Use shell scripts to increase leverage and portability.

束縛するインターフェースは作るな。
Avoid captive user interfaces.

全てのプログラムはフィルタとして振る舞うようにせよ。
Make every program a Filter.

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

モジュール性のルール
Rule of Modularity

Developers should build a program out of simple parts connected by well defined interfaces, so problems are local, and parts of the program can be replaced in future versions to support new features. This rule aims to save time on debugging code that is complex, long, and unreadable.

　→　クリーンなインターフェースで接続されるシンプルなパーツを書け。

明瞭さのルール
Rule of Clarity

Developers should write programs as if the most important communication is to the developer, including him- or herself, who will read and maintain the program rather than the computer. This rule aims to make code readable and comprehensible for whomever works on the code in future.

　→　明瞭さは独創性よりも良い。

合成のルール
Rule of Composition

Developers should write programs that can communicate easily with other programs. This rule aims to allow developers to break down projects into small, simple programs rather than overly complex monolithic programs.

　→　他のプログラムと接続できるようプログラムをデザインせよ。

分割のルール
Rule of Separation

Developers should separate the mechanisms of the programs from the policies of the programs; one method is to divide a program into a front-end interface and back-end engine that interface communicates with. This rule aims to let policies be changed without destabilizing mechanisms and consequently reducing the number of bugs.

　→　ポリシーをメカニズムから分離せよ。インターフェースをエンジンから分離せよ。

シンプルさのルール
Rule of Simplicity

Developers should design for simplicity by looking for ways to break up program systems into small, straightforward cooperating pieces. This rule aims to discourage developers’ affection for writing “intricate and beautiful complexities” that are in reality bug prone programs.

　→　シンプルさを求めてデザインせよ。複雑にしなければならない場合に限り、複雑さを加えよ。

倹約のルール
Rule of Parsimony

Developers should avoid writing big programs. This rule aims to prevent overinvestment of development time in failed or suboptimal approaches caused by the owners of the program’s reluctance to throw away visibly large pieces of work. Smaller programs are not only easier to optimize and maintain; they are easier to delete when deprecated.

　→　他に方法がないことが実験により明らかである場合に限り、大きいプログラムを書け。

透明性のルール
Rule of Transparency

Developers should design for visibility and discoverability by writing in a way that their thought process can lucidly be seen by future developers working on the project and using input and output formats that make it easy to identify valid input and correct output. This rule aims to reduce debugging time and extend the lifespan of programs.

　→　透明性を求めてデザインせよ。調査とデバッグが簡単になる。

頑丈さのルール
Rule of Robustness

Developers should design robust programs by designing for transparency and discoverability, because code that is easy to understand is easier to stress test for unexpected conditions that may not be foreseeable in complex programs. This rule aims to help developers build robust, reliable products.

　→　頑丈さは透明性とシンプルさから生まれる。

代表のルール
Rule of Representation

Developers should choose to make data more complicated rather than the procedural logic of the program when faced with the choice, because it is easier for humans to understand complex data compared with complex logic. This rule aims to make programs more readable for any developer working on the project, which allows the program to be maintained.[6]

　→　知識をデータに織り込め。するとプログラムのロジックをつまらなくて頑丈なものにできる。

最小限の驚きのルール
Rule of Least Surprise

Developers should design programs that build on top of the potential users' expected knowledge; for example, ‘+’ should always mean addition in a calculator program. This rule aims to encourage developers to build intuitive products that are easy to use.

　→　インターフェースデザインにおいては、常に驚きが最小限であるようにせよ。

沈黙のルール
Rule of Silence

Developers should design programs so that they do not print unnecessary output. This rule aims to allows other programs and developers to pick out the information they need from a program's output without having to parse verbosity.

　→　プログラムを余計な出力を出させない。

修復のルール
Rule of Repair

Developers should design programs that fail in a manner that is easy to localize and diagnose or in other words “fail noisily”. This rule aims to prevent incorrect output from a program from becoming an input and corrupting the output of other code undetected.

　→　失敗しなければならないときは、騒がしく、かつできるだけ早く失敗せよ。

経済のルール
Rule of Economy

Developers should value developer time over machine time, because machine cycles as of the year 2013 are relatively inexpensive compared to prices in the 1970s. This rule aims to reduce development costs of projects.

　→　プログラマの時間は貴重である。プログラマの時間をコンピュータの時間より優先して節約せよ。

生成のルール
Rule of Generation

Developers should avoid writing code by hand and instead write abstract high-level programs that generate code. This rule aims to reduce humans errors and save time.

　→　hand-hacking[3]は避けよ。プログラムを書けるときに、プログラムを書くためにプログラムを書け。

最適化のルール
Rule of Optimization

Developers should prototype software before polishing it. This rule aims to prevent developers from spending too much time for marginal gains.

　→　洗練させる前に原型（プロトタイプ）を作れ。最適化する前に原型が動くようにせよ。

多様性のルール
Rule of Diversity

Developers should design their programs to be flexible and open. This rule aims to make programs flexible, allowing them to be used in other ways than their developers intended.

　→　あらゆる「ただ一つの本当の方法」という主張は信じるな。

拡張性のルール
Rule of Extensibility

Developers should design for the future by making their protocols extensible, allowing for easy plugins without modification to the program's architecture by other developers, noting the version of the program, and more. This rule aims to extend the lifespan and enhance the utility of the code the developer writes.

　→　未来に向けてデザインせよ。未来は思ったよりもすぐにやってくる。