「UNIXという考え方」を読んだ

UNIXという考え方―その設計思想と哲学 / @soh335 memo

面白くないだろうなと思って読んだけど面白かった。
ただ時代背景をちゃんと理解しないと何言ってんだオッサンみたいになる。

移植性の話でシェルスクリプトが礼賛されてるけど
今だとクロスコンパイルの効くgolangが良いと思う。

UNIXというか、Linuxを使ってると、入力コマンドをたった1byte間違えただけで
OSが吹っ飛んだり、ちょっと間違えた時に昔の状態に戻れないの
もしかしたら何十年後かにはそんなこともあったね。みたいな話になってるかもしれない。

コマンドの成否をOSがフォローするよりも、バージョン管理システムみたいに
そのコマンドによってファイルシステム上のファイルに変更があった場合、
コマンド実行以前の状態に戻す。みたいなのできたら最高だと思う。

シェルスクリプト、とても便利でsystem()とかecho ~のように
外部コマンド呼び出さなくても良いのが利点だけど、
テストするのに毎回echo "command"みたいにprint debugぐらいしかできなくて
石器時代の代物にはかわりないと思う。

けど、その辺はわりかしどうでもよくてこの本の面白かったところは他にあった。

スモール・イズ・ビューティフル

プログラミング初心者なので、ゴリっとしたでかいコード見ると
おお、すげぇ。。。って思うけど、実際は目的に対して少ないコードが良いし
行き着く先は無刀の境地みたいに、1行もコード書かないで目的が達成されるのが最高で
プログラムを書く場合に、量は少なくシンプルに、読んでわかりやすいコードを目標にすべきなんだ。

ひとつのプログラムにはひとつのことだけさせる

ひとつのメソッドで色んな機能盛り込まない的な話だ。

できるだけ早く試作を作成する

アジャイルだ。

ソフトウェアの梃子を使う

先人が書いたコード、拝借できるものは拝借した方が効率が良いって話だ。

対話的プログラムの危険性

おしゃべりなプログラムは例外発生させた時にわけわからん動作したりするから
最低限の機能にすべきって話だ。

感想

色々面白いところはあったけど、lsのコマンドオプションの多さの問題点や、
100％を完成としないで90%で完成とした方が良いみたいなことは昔から言われていたんだ。
っていうことを知れて面白かった。

本書の中の抜粋なんだけど「人月の神話」に
「開発プロジェクトがある程度進行した段階でプログラマを追加投入すると、完成は早まらずむしろ遅れる」
っていうことが書いてあるらしく、電車の中で笑ってしまった。