The Art of UNIX Programming

Unix の暗黙知を明文化!

本書は Unix の大御所の一人である Eric S. Raymond が書き下ろした Unix プログラミングの入門書です。
しかし、プログラミングの入門書といっても、本書にはほとんどソースコードが出てこないですし、API を用いたプログラミングの説明もありません。では、いったい本書には何が書かれているのでしょうか?
本書には、Unix の専門家なら当然のように知っているが、明文化されてこなかった暗黙知が記されています。Unix のグルが弟子に口頭で伝えてきた知識が、はじめて本の形にまとめられたのです。
本書を読むことで、Unix というオペレーティングシステムの背後にある思想、Unix 的プログラミングの考え方が理解できるでしょう。
著者は、本書のことを「how-to 本」ではなく「why-to 本」だと述べています。ぜひ、Unix の「なぜそうするのか?」「なぜそうなっているのか?」を理解してしていただきたいと思います。
序章
第 1 章 思想: 大切なのは思想だ
第 2 章 歴史: 2 つの文化の物語
第 3 章 対比: Unix 思想と他の OS
第 4 章 モジュール化: 簡潔に、単純に
第 5 章 テキスト形式: 優れたプロトコルが優れた実践を生む
第 6 章 透明性: 光あれ
第 7 章 マルチプログラミング: プロセスを機能別に分割する
第 8 章 ミニ言語: 歌いだす記法を探す
第 9 章 コード生成: 高い水準で規定する
第 10 章 設定: 気持ちよくスタートしよう
第 11 章 ユーザーインターフェイス: Unix 環境におけるユーザーインターフェイス設計
第 12 章 最適化
第 13 章 複雑さ: できる限り単純に、それよりも単純でなく
第 14 章 言語: C すべきか C せざるべきか?
第 15 章 ツール: 開発の戦略
第 16 章 再利用: やり直しを避けること
第 17 章 移植性: ソフトウェアの移植性と標準の維持
第 18 章 ドキュメント: Web 中心の世界でコードの説明をする
第 19 章 オープンソース: 新しい Unix コミュニティでのプログラミング
第 20 章 未来: 危険と可能性
略語集
参考文献
寄稿者紹介
無根的根: 不宇先生の Unix 公案

『The Art of UNIX Programming』 (Eric S. Raymond 著、長尾 高弘 訳、ドワンゴ発行、KADOKAWA 発売、2019 年 3 月刊) は、Unix の世界で受け継がれてきた設計の考え方を、プログラムのコードではなく言葉で説明する本です。原書は 2003 年 9 月に Addison-Wesley Professional から刊行され、この日本語版は国立国会図書館の書誌でアスキー 2007 年刊の再刊と記録されています。版元の紹介文は、本書を Unix の専門家なら当然のように知っているが明文化されてこなかった暗黙知をまとめた本と説明し、ほとんどソースコードが出てこないこと、著者自身が how-to 本ではなく why-to 本と述べていることを伝えています。Unix 的なプログラムが「なぜそう作られているのか」を理解したい開発者のための一冊です。

序章と全 20 章の構成、思想と歴史から実践と未来まで

構成は序章と第 1 章から第 20 章までで、多くの章題が「キーワード: 説明」の形をとっています。第 1 章から第 3 章は思想、歴史、他の OS との対比で、Unix の考え方そのものと、それが生まれた背景を扱います。第 4 章から第 13 章は設計の論点で、モジュール化、テキスト形式、透明性、マルチプログラミング (プロセスを機能別に分割する)、ミニ言語、コード生成、設定、ユーザーインターフェイス、最適化、複雑さが並びます。第 14 章から第 19 章は開発の実践に寄り、言語の選び方、ツール、再利用、移植性と標準の維持、ドキュメント、オープンソースのコミュニティでのプログラミングを取り上げ、第 20 章は未来: 危険と可能性で締めくくられます。巻末には略語集、参考文献、寄稿者紹介に加えて、「無根的根: 不宇先生の Unix 公案」が収められています。

モジュール化とテキスト形式が設計判断に効く理由

Unix の考え方としてよく知られるのは、一つのことをうまくこなす小さなプログラムを作り、テキストの入出力でつなぎ合わせるという姿勢です。これが設計の指針として強いのは、部品どうしの約束を単純な形に保つほど、部品を差し替えたり組み替えたりしても全体が壊れにくくなるからです。第 4 章のモジュール化は、部品の間の 結合度 を低く保つ話として読むことができ、第 5 章のテキスト形式は、データを人が読める形で残すことが、デバッグや別の道具との連携をどれだけ容易にするかという話につながります。第 6 章の透明性は、動作の中身が外から見えるように作ることで保守と障害調査の手間を減らす考え方です。第 13 章の章題「できる限り単純に、それよりも単純でなく」は、KISS 原則 のように単純さを求めつつも、必要な複雑さまで削らない線引きを主題にしていると読めます。いずれも特定の言語やフレームワークに依存しない論点なので、Unix 以外の環境で設計をする人にとっても判断の物差しになります。

2003 年の原書を前提に読む点と、合う読者

原書は 2003 年の刊行で、扱われる道具や環境、第 18 章の Web 中心の世界でのドキュメントや第 19 章の オープンソース のコミュニティについての記述も、その時点の状況を前提にしています。版元の紹介文が述べるとおりソースコードや API の使い方の説明はほとんどないため、Linux のコマンドやシステムコールの使い方を手順で覚えたい人には目的が合いません。そうした目的なら、まず手を動かす入門書を一冊通してから本書に戻るほうが、章ごとの論点が自分の経験と結びつきやすくなります。

一方で、ツールやライブラリを作る立場になり、インターフェイスの切り方や設定ファイルの形式、ミニ言語を導入するかどうかといった判断を自分で下す必要が出てきた開発者にとって、本書はその判断の背景にある考え方をまとめて手に入れられる本です。古い本から何を受け取り、何を割り引いて読むかについては 技術書の古典を読む意味 も参考になります。設計の「なぜ」を言葉で説明できるようになりたい人には、時間をかけて読む価値のある一冊です。