Unix規範(翻訳)

1. 小さいものは美しい。
  • 小さいプログラムは理解しやすい。
  • 小さいプログラムは保守が簡単。
  • 小さいプログラムはシステム資源の消費が少ない。
  • 小さいプログラムはほかのツールと結合しやすい。
2. 一つのプログラムには一つのことをやらせる。
  • 「最高のプログラムは...そのライフタイムで一つの仕事をうまく行うプログラムだ。」
  • 「そのプログラムは、メモリにロードされ、その機能を完遂し、そして、一つの事に注力する次のプログラムが開始できるように去って行く。」
3. できるだけ早く試作する。
  • 試作は学習過程である。
  • 早い試作はリスクを減らす。
4. 効率よりも移植性。
  • 来年/来四半期/来月のハードウェアはより速くなる。
  • プログラムの高速化に多くの時間を使うな。
  • 最も効率的な方法には、移植性はほとんどない。
  • 良いプログラムは不滅 --- それらは新しいハードウェアプラットフォームに移植される。
5. 数値データは単純な ASCII ファイルに保存する。
  • ASCII テキストは共通交換フォーマット。
  • ASCII テキストは簡単に読めて簡単に修正できる。
  • ASCII テキストファイルは Unix テキストツールを単純に使用できる。
  • 高い移植性が(フラットな ASCII テキストファイルの)スピード不足を克服する。
  • スピード不足は来年のマシンで克服される。
6. ソフトウェアの梃子(てこ)を強みにする。
  • 良いプログラマーは良いコードを書く、卓越したプログラマーは良いコードを「借りて」くる。
  • NIH症候群(自社開発主義症候群)を避ける。
  • コードを他の人が自分の仕事に梃子として利用することを許す。
  • 全てを自動化する。
7. シェルスクリプトで梃子の効果と移植性を高める。
  • シェルスクリプトには素晴らしい梃子の効果がある。
  • シェルスクリプトは時間節約にも効果がある。
  • シェルスクリプトは C言語よりも移植性が高い。
  • シェルスクリプトを C言語で書き直す誘惑に負けるな。
8. 拘束的ユーザインタフェース(CUI)は避ける。
  • CUI は人の使用を前提としている。
  • CUI のパーサはしばしば大きく醜いものとなる。
  • CUI は「大きいものは美しい」アプローチを採用する傾向にある。
  • CUI を持つプログラムは他のプログラムとの結合が困難。
  • CUI にはあまりスケーラビリティがない。
  • CUI はソフトェア梃子の利点を持たない。
9. 全てのプログラムをフィルタにする。
  • コンピュータのはじまり以来、全てのプログラムはフィルタである。
  • プログラムはデータを作らない --- 人が作る。
  • コンピュータはデータをある形式から別の形式へ変換する。
  • stdinをデータ入力に使う。
  • stdoutをデータ出力に使う。
  • stderrをその他の情報に使う。
〈 補足的 10項目 〉
  1. 環境のカスタマイズが可能とする。
  2. オペレーティングシステムの核を小さく軽く作る。
  3. 小文字を使う、短くする。
  4. 樹木を守る。
  5. 沈黙は金。
  6. 並行に考える。
  7. 部分の総和は全体より偉大。
  8. 90%の解を求める。
  9. 悪いは良い。
  10. 階層的に考える。

The UNIX Philosophy(原文)

Tenets of the UNIX Philosophy

from The Unix Philosophy by Mike Gancarz

ISBN:1-555558-123-4. Copyright 1995 Butterworth-Heinemann.

Reprinted with Permission of Digital Press

The main tenets of the Unix Philosophy are as follows:

  1. Small is beautiful.
    • Small programs are easy to understand.
    • Small programs are easy to maintain.
    • Small programs consume fewer system resources.
    • Small programs are easier to combine with other tools.
  2. Make each program do one thing well.
    • "The best program...does but one task in its life and does it well."
    • "The program is loaded into memory, accomplishes its function, and then gets out of the way to allow the next single-minded program to begin."
  3. Build a prototype as soon as possible.
    • Prototyping is a learning process.
    • Early prototyping reduces risk.
  4. Choose portability over efficiency.
    • Next ---'s hardware will run faster.
    • Don't spend too much time making a program run faster.
    • The most efficient way is rarely portable.
    • Good programs never die--they are ported to new hardware platforms.
  5. Store numerical data in flat ASCII files.
    • ASCII text is a common interchange format.
    • ASCII text is easily read and edited.
    • ASCII data files simplify the use of Unix text tools.
    • Increased portability overcomes the lack of speed (of flat ASCII text files...)
    • The lack of speed is overcome by next year's machine.
  6. Use software leverage to your advantage
    • Good programmers write good code; great programmers "borrow" good code.
    • Avoid the not-invented-here syndrome.
    • Allow other people to use your code to leverage their own work.
    • Automate everything.
  7. Use shell scripts to increase leverage and portability.
    • Shell scripts give you awesome leverage
    • Shell scripts leverage your time, too.
    • Shell scripts are more portable than C.
    • Resist the desire to rewrite shell scripts in C.
  8. Avoid captive user interfaces.
    • CUIs assume that the user is human.
    • CUI command parsers are often big and ugly to write.
    • CUIs tend to adopt a "big is beautiful" approach.
    • Programs having CUIs are hard to combine with other programs.
    • CUIs do not scale well.
    • CUIs do not take advantage of software leverage.
  9. Make every program a filter.
    • Every program written since the dawn of computing is a filter.
    • Programs do not create data--people do.
    • Computers convert data from one form to another.
    • Use stdin for data input;
    • Use stdout for data output;
    • Use stderr for out-of-band information.

Ten Lesser Tenets

  1. Allow the User to tailor the environment.
  2. Make operating system kernels small and lightweight.
  3. Use lower case and keep it short.
  4. Save Trees.
  5. Silence is golden.
  6. Think parallel.
  7. The sum of the parts is greater than the whole.
  8. Look for the 90 percent solution.
  9. Worse is better. (I won't try to explain this one...)
  10. Think hierarchically.

"Unix owes much of its success to the fact that its developers saw no particular need to retain strong control of its source code."