単純さはいつも最高ではない
まつもとゆきひろ氏：「最も単純なプログラミング言語は何ですか？」という質問をするとですね……文法的にという意味なんですけども。
初期の言語として、Lisp、FORTH、APLなど、みんな1960年代ぐらいに作られた言語ですが、こういうものが挙げられます。
Lispは1960年ぐらいに作られた言語ですし、FORTHは、1960年代終わりぐらいから1970年代の頭にかけて。APLは、1963年に論文が発表されて実装が出たのは1965年ですね。どれも今から60年ぐらい前のプログラミング言語です。
文法的には非常に単純です。現在において、LispやFORTHやAPLでプログラミングしている人はいるかというと、いるんですけど。
特にFORTHは不思議な言語ですね。みなさんの持っているコンピューターにもFORTHは載っているんですね。
実は、最近BIOSというのがなくなって、UEFIというのが載っているんですが、いわゆるコンピューターがブートする時のブートローダーというプログラムにFORTHが載っているんですね。みなさんの知らないところでFORTHが動いているということですね。
あと、プリンターにPostScriptというのがありますよね。あれは、純粋にはFORTHではないのですが、FORTHの影響を非常に強く受けたプログラミング言語なんですね。
ですから、みなさんの見ていないところで、FORTHは非常に大活躍しているんです. ただ、「実際にFORTHのプログラムを見たことある人はいますか？」という話をすると、ほとんどいないのが現実だと思います。
こういう単純なプログラミング言語があまり流行らなかった理由は何かというと、またPerlが出てくるんですが、Perlを作ったラリー・ウォールさんが言ったような気がする言葉があります（笑）。（スライドの）「-ish」というのはそういう意味です。
「もしプログラミング言語が単純だったら、私たちの各ソフトウェアは、より複雑になるだろう」と。「なぜならば、複雑さの総和、存在する複雑さっていうのは、定数だから」ですね。つまり、プログラミング言語があまり複雑じゃないと、アプリが複雑になると。プログラミング言語がある程度複雑だと、アプリはよりシンプルになる傾向があるということですね。
これは、たぶん『プログラミングPerl』というラクダが表紙になっている本の脚注に書いてあったと思うのですが、私の家の本棚には『プログラミングPerl』が見当たらなくてですね、ちょっと時間切れで正確な文面を見つけることができなかったんですが、ラリー・ウォールがこれを言っていたはずです。
なので、「Simple is the best」。みたいによく言いますが、実際問題として、少なくともプログラミング言語やシステムに関していうと、単純さはいつも最良ではないということですね。
人間の心そのものが複雑ですし、それから構成される人間の社会も複雑ですし、人間の社会から発生する解決すべき問題も複雑だからですね。私たちは自分の持っているメンタルモデル、複雑なことを無意識に考えてしまう。それに従って、現実を認めなければいけないという意味だと思います。
必ずしも「大きいことはいいこと」ではない
ほかに注目すべきプログラミング言語をいくつか紹介しておきます。
PL/I。みなさんあまり知らないと思いますが、昔々、1960年代から1970年代ぐらいにかけて、COBOLというプログラミング言語と、FORTRANっていうプログラミング言語の非常に人気が高かったんですね、シェアが高かったんです。
FORTRANというプログラミング言語は、数値計算ですね。科学技術計算などに使われていました。COBOLは事務処理に使われていました。
そうすると、多くのユーザーが「いいことを考えた。COBOLの機能とFORTRANの機能を1つの言語にまとめたら、1個で全部できてうれしいじゃん」と思ったんですね。自然な発想ですよね。
それで、「Programming Language One」、つまり1つでなんでもできるプログラミング言語を作ろうと思ったんですね。すばらしいアイデアですね。ですが、うまくいかなかったんです。やはりあまり違うものを1個にするとろくなことにはならないということですね。
もう1つ、Adaというプログラミング言語があったんですね。これは、世界最初のプログラマーと言われるエイダ・ラブレスという人から名前を取ったプログラミング言語です。
アメリカの国防総省、Department of Defenseだったっけ（笑）。アメリカの国防総省が、使うシステムですね。例えば戦闘機を管理するシステムや潜水艦を管理するシステムなどを作るために、なんでもできる言語が必要だと。国防総省のすべての情報システムを記述できるようなプログラミング言語があったらいいだろうと、やはりなにもかも突っ込むんですね。
どうなったかというと、現在においてPL/Iを使っている人はいないですね。Adaを使っている人は、実はいるそうなんです。今でも「F-35」のシステムの一部はAdaで書かれていると聞いたことがありますが、一般の人がAdaを使う機会はあまりなくなっていますね。
これはなんでかというと、単純さは良くないと今言ったばかりなんですが、複雑すぎるのもやはり良くなくて、人間はあまり複雑だと扱うことができないんですね。
複雑なものにはいろいろ種類があります。Rubyでもそうなんですが、システムをデザインしていると、「あの機能が欲しい」とか「この機能が欲しい」という要求があったり、自分も思いついたりするので、もうどんどん入れていくんですけども。
こういうのを「Creeping Featurism」と言うらしいです。「Creeping」は、虫とかが「這い寄る」という意味ですね。「Feature」は、「機能」。だから、あの機能、この機能と少しずつ這い寄ってきて、だんだんだんだん肥大化していくんですね。これは非常に危険です。
この複雑さにも注意があって、線形な複雑さはまだましなんですね。具体的に言うと、例えばStringクラスにメソッドが1個増えるというのは、線形な複雑さなんですね。
ところが指数関数的な複雑さというのは、だいぶたちが悪い。あの機能とこの機能を組み合わせて、とすると「別の機能を組み合わせた時はどうなるの？」とか、そういう組み合わせが発生する複雑さは、たちが悪いんですよね。
たちが悪いほうの複雑さとしては、例えばC++のテンプレートなどがありますよね。何が起きるかがわからないという。C++でテンプレートをプログラミングすると、1,000行ぐらいエラーメッセージが出ることがあるんですね。やめてくれという感じですが、こういうのが指数関数的な複雑さですね。
結果としては、「大きいほうがいいことだ」「大きいことはいいことだ」という言われ方をすることもありますが、システムに関しては、必ずしもそうとは限らないということを私たちは学ぶことができます。
（次回へつづく）
