「Paul Grahamのプログラミング言語観・その１」の続き。
プログラミング言語は簡潔であるべし
これは、やりたいことが手間少なくできるということだ。簡単な記述でやりたいことが実現できればハッカーは本来やるべきことにより集中することができる。ハッカーの役割はコードを書くことではない。ハッカーが本来力をそそぐべきはソフトウェアをデザインすることだ。
その意味で、プログラミング言語の簡潔さは、プログラミング言語の強力さに通じる。簡潔さを備えたプログラミング言語は、ハッカーの創造性をよりリアルタイムにソフトウェアへと反映させるのだ。
コンパイラが必要とするという理由で書かなければならないような記述は冗長といえる。プログラミングは人間の創造性を生かすための道具として使役されるべきものだ。コンピュータのためにプログラミングをするわけではない。（その理由でGrahamは静的な型付けに否定的だ。）
非効率なソフトウェアが醜いのではない。醜いのは、プログラマに不要な仕事をさせる言語だ。本当の非効率性とは、マシンの時間を無駄にすることではなく、プログラマの時間を無駄にすることだ。コンピュータが速くなればなるほど、このことははっきりしてくる。
「百年の言語 --- The Hundred-Year Language」には将来において進化をしていくであろう言語について、このような記述がある。
私の勘だが、進化樹の主要な枝は、最も小さくクリーンなコアを持つ言語を通っているのだと思う。言語の残りの部分をその言語自身で書くことができる余地が大きければ大きい程、良い。
これがGrahamが理想とする簡潔さと強力さというものを端的に語っていると思う。
そして、これに加え今後のプログラミング言語のトレンドとしてGrahamが最重要視するのがライブラリだ。（意味的に、フレームワークと呼ばれるものもここに含まれるだろう）
この先50年のプログラミング言語の進化は、ライブラリ関数に関するものになるだろうと思う。未来のプログラミング言語は、言語のコアと同じくらい慎重に設計されたライブラリを備えているだろう。プログラミング言語の設計の重点は、強い型付けにするか弱い型付けするかとかオブジェクト思考にするかとか関数型にするかとかそういうことではなく、どうやったら素晴らしいライブラリを設計できるかということになってゆくだろう。
そして、良いライブラリの定義についても書いてある。
良いライブラリを設計するのは難しい。たくさんのコードを書けば良いというものではない。ライブラリが大きくなりすぎると、必要な関数を探し回るより自分で書いてしまった方が早いなんてことが起こる。ライブラリは、コア言語と同様に、小さな直交性の高い操作を使って設計されなければならない。プログラマが、どのライブラリが欲しい機能を実行できるかを推測できるようになっていなければならない。
RoRの簡潔さは有名だ。異説もあるが、Javaフレームワークの10倍の開発効率を誇るというフレコミで非常に高い注目を集めている。10倍云々の真偽はさておき、プログラミング言語にとって良いライブラリがあるということが非常に重要な点になっていることは真実だろう。
私の知る限り、この問題について最初に書いたのはFred Brooksだ。彼は「人月の神話」の中で、平均的なプログラマが生産できるコードの行数は言語によらずほぼ一定であると述べていたと思う。私は確か、学部生か大学院に入りたての頃にそれを読んで新鮮な驚きを受け、その意味するところは非常に大きいと感じた。だってそこから得られる結論は、 (a) ソフトウェアをより速く書く唯一の方法はより簡潔な言語を使うことで、 (b) その手間を掛けた者はそうしなかった競争相手をはるか後方に引き離すことが出来る、ってことだからだ。
ビジネスにおいても、簡潔かつ強力な言語を使うということはそれだけで優位性になり得る。強力な言語で実装されたある機能を実現するために、力の弱い言語で開発する企業は数倍大きな時間と資金を必要とするだろう。
