0. はじめに
こんにちは。都内でエンジニアをしている、@gkzvoiceです。
先日、Twitterのタイムラインに@nukumaro22さんからこんな投稿が流れてきました。
これは哲学書です pic.twitter.com/4lMKQtOuAV
— iberianpig(Kohei Yamada) (@nukumaro22) June 4, 2020
というわけで、早速、Amazonでポチり、読んでみました。
本書を読んで、覚え書きをしていたので、インターネットに放流したいと思います。
書評っぽい内容ですが、タイトルに書評と付け忘れました。。
1. 本書の目次
- 第1章 UNIXの考え方:たくさんの登場人物たち
- 第2章 人類にとっての小さな一歩
- 第3章 楽しみと実益をかねた早めの試作
- 第4章 移植性の優先順位
- 第5章 これこそ梃子の効果!
- 第6章 対話的プログラムの危険性
- 第7章 さらなる10のUNIXの考え方
- 第8章 一つのことをうまくやろう
- 第9章 UNIXとその他のオペレーティングシステムの考え方
2. 本書のおすすめポイント
-
内容が全く古臭くない
- 2001年初版発行、私が読んだものは2008年第14刷発行と10年以上前に書かれたもの。
- 中身は特定の技術にフォーカスしたものではない。
- むしろ
「哲学的」なお話。 - 時代が変われど変わらない考え方を取り上げているせいか、UNIXの思想は、
マイクロサービスの思想やザッカーバーグ氏のあまりに有名な言葉の「Done is better than perfect.」に通じる。
-
空き時間に読めるほどのコンパクトさ
- 仕事や勉強の箸休めに読むのもいいかもしれない。
3. 読んで印象に残ったこと
3-1.コマンドの結果をカラとするのには理由がある
- lsコマンドの結果、該当ファイルがなければ、コマンドの実行者に該当ファイルが存在しないことを"not found"などと伝えるようにするべきかもしれない
- しかし、その結果を別のコマンドに渡すとなると出力結果はファイル名かカラのほうが処理が単純となる。
- lsコマンドの使い勝手という面では`一見配慮に欠けた実装(該当ファイルがあれば出力し、なければ出力しない)のほうが開発者にとって都合がいい。
3-2.Worse is better.
- UNIXの思想のひとつ
- いまいちピンときていなかったが、@t_wadaさんのTweetを拝見して腑に落ちた
Worse Is Better に関する自分の解釈は「設計の正しさ/美しさと実装の単純さが対立する（両立できない）ときは、実装の単純さを選択した方が、たとえそれが漏れのある抽象になったとしても現実の問題を解決し、実装の単純さによって開発参加のハードルが下がり、進化的な強さを獲得できる」というもの
— Takuto Wada (@t_wada) April 6, 2018
- 自分の言葉で説明すると、こんな具合
- 複雑性は増すけどよりよい設計と、それらは劣るけど単純な設計のうち、後者を選択すると、コントリビュートの敷居を下げ、長い目で見ると前者より優れたものとなる。
3-3.Worse is betterの先にあるもの
- 本書では、Worse is betterについて、このように続けている。
「良くなる」ためには、単純さを犠牲にして完全性を追求しなければならない。そうなるとUNIXはもはやUNIXではなくなる。
-
一見自己矛盾を抱えているように思えるけど、**
「良くなったUNIX」は非連続的な発展を遂げ、別次元のworse is betterなもの**であってほしいと思った。 -
Linuxカーネルは肥大化しているとは実際どういうことなのか分かっていないけど、Linuxカーネルの肥大化はその一例かも
3-4.本書の話題から外れるけどLinuxカーネルのメンテナーの仕事内容
- @komi_edtr_1230さんの投稿を拝見してLinuxカーネルのメンテナーの仕事の内容が気になった
- これは宿題
Linuxカーネルのコアのメンテナーの多くは50代や60代で、これからLinuxも次の世代へと引き継いでいく必要があり、その中でひょっとしたらLinuxカーネルがCではなくRustのような別の言語で書かれる可能性もあるし、何かしらの変化が起こるかも、と。 https://t.co/TvvFoIFvMJ
— コミさん (@komi_edtr_1230) July 1, 2020