読書メモ：The Rise of "Worse is Better"
逆説的でキャッチーなフレーズ「Worse is Better」の原点であるRichard GabrielのThe Rise of "Worse is Better"を再読したのでメモ。
概要
The Rise of "Worse is Better"は1989年にRichard Gabrielが書いた「Lisp: Good News, Bad News, How to Win Big」という商業Lisp業界のそれまでとその後の展望を語った文章の一章。1991年にLucid社員のJamie Zawinski（Coders at Workにも出てた）が発見してインターネットに放出して有名になったらしい。
LispとC言語を対比させ、それらの開発母体であるMITとNew Jersey（ベル研究所の所在地）のローカルな哲学の違いが言語仕様を制定するさいの優先順位に影響を与え、結果それらの言語の成功の度合いも決定した、というのが文書の主張。そしてNew Jerseyの哲学を要約すると「Worse is Better」となる。
作者
作者であるRichard GabrielはLisp界隈の有名人。ただし一般的にはこの文書とWorse is Betterというフレーズが一番有名だろう。
他の功績としてはなんと言ってもCommon Lispの生みの親の一人であるという点。様々な団体が様々なアーキテクチャ向けに独自のLispを開発・販売していたのを、一つの規格へと統一するARPA主導のプロジェクトであったCommon Lisp。そのデザイナー五人衆（Quinquevirateと呼ばれていたらしい）にGuy Steele, David Moon, David Weinreb, Scott Fahlmaとともに名を連ねている。
またGNU EmacsのフォークであるXEmacsを開発していたLucid社の創業者でもある。この会社は元々Lisp関連の開発をしていたのが、その後他の事業にピボットしたという経緯がある（創業10年で倒産するのだが）。「Lisp: Good News, Bad News, How to Win Big」を書いた時点でのGabrielの肩書きはLucidのCEO。
詳細
この記事は話の流れとしては以下の４つに分かれる：
- MITとNJの哲学をSimplicity, Correctness, Consistency, Completenessの四つの目的に対する優先順位の違いで解説
- 実際のMITとNJのOS研究者の会話をアネクドートとして紹介
- なぜNJ方式がソフトウェア戦略として優れているのか
- なぜMIT方式は問題があるのか
MITとNJの哲学
MITの哲学は"the right thing"、NJの哲学は"Worse is Better"。
MIT哲学の優先順位はCorrectness = Consistency > Completeness > Simplicity (Interface) > Simplicity (Implementation)
NJの哲学はSimplicity (Implementation) > Simplicity (Interface) > Correctness > Completeness > Consistency
（注：Simplicity (Interface)の順位は原文からは不明瞭なので上記の不等式は推測も含まれる）
MITとNJのOS研究者の会話
割愛
なぜNJ方式がソフトウェア戦略として優れているのか
NJ方式だとうまくいく理由が三点挙げられている：
- 実装のシンプルさが何よりも優先されるので、新しいアーキテクチャへのポートコストが低く、またリソース要求も低い（ので多くのプラットフォームに広まりやすい）
- ユーザであるプログラマも実行効率とリソース効率を得るために安全性や利便性を犠牲にすることに慣れるので、NJ式の言語やOSの上で書かれるプログラムも広まりやすい
- 複雑でモノリシックなプログラムを書けるほど表現力が強くないので、自然と再利用可能なコンポーネントを組み上げるスタイルの開発になる
必要と思われる機能の５割だけ実装されているとしても、上記の理由でウイルスのように広まりやすく、そして一旦広まってしまえば機能を９割まで上げる経済的なインセンティブが生じるので、最終的にはいいプロダクトになっていく。
なぜMIT方式は問題があるのか
MIT方式の結果は「big complex system」か「diamond-like jewel」のどちらかになる。
big complex systemの特徴は、大きく複雑で考え得る機能が網羅されている。デザイン、実装に非常に時間がかかり、利用するのに複雑なツールが必要となり、実行する環境に対するリソース要求が高い。例はCommon Lisp。
diamond-like jewelの特徴はコンパクトなのだけど完璧にデザインするために開発にやはり非常に時間がかかること。また実行効率の良い実装はほぼ不可能。例はScheme。
このような実装に時間がかかって、その上広まりにくいようなソフトが出来上がるthe right thingという哲学はソフトウェア開発においてはそぐわず、これはLisp業界にとって悩ましい問題である、という結論で終わっている。
感想
メッセージパッシングのちょうどよさのはなしを読んでいて、ひさしぶりにWorse is Betterへの言及を見たのでこれを機に読み直してみた。
以前はかなり感心した覚えがあるのだが、今回読み直してみて少し話の持っていきかたが強引な気もした。
プラットフォームがNJ式なことと、そのプラットフォーム上で書かれるプログラムがNJ式なのとは別問題じゃないか？あと実装が簡単だからといって低リソースな状況で強いかどうかもまた別では・・・？
まあDon't Let Perfect be the Enemy of Goodという話に関してはその通りだとは思うが、それ以外では前提条件がけっこう限定的な印象。
余談だがWorse is Betterが優れているのを説明する部分で
The good news is that in 1995 we will have a good operating system and programming language; the bad news is that they will be Unix and C++.
というフレーズが出てくるのだが
The good news is that in 2000 we will have a good operating system and programming language; the bad news is that they will be Windows and Java.
あるいは
The good news is that in 2015 we will have a good operating system and programming language; the bad news is that they will be Chrome and JavaScript.
という世界線から見直すとどうだろう。JavaもJavaScriptも「Worse is Better」な思想かどうかは別としてウイルス的に爆発的に広がる理由があったのは事実。
Javaは巨大なVMでマシンアーキテクチャの違いを吸収して「Write once, run anywhere」を目指すという、ある意味「the right thing」な思想だったようにも思う（Guy Steeleが関わっていたという点も面白い）。「the right thing」でもスケールできるぞ、というアンサーソングだと妄想してみると楽しい。
JavaScriptはブラウザという爆発的に増えた生物の遺伝子コードにたまたま乗っかっていた、という感じだ。言語としては確かに「the right thing」を目指さなかった（時間的制約もあって目指せなかった）というところはあると思うけど、必ずしも「worse is better」を狙った感じではないし、「worse is better」だったから広まったわけでもなさそう。
