2010/02/15

仕事でLispを使うこと(2)

仕事でLispを使うことの続き。

Lispが力を発揮する一例として、高レベルから低レベルまでの アクセスが必要な場合というのをあげたけれど、もう少し考えを進めてみる。

さくっと作れることが利点である言語、まあいわゆるLLと呼ばれてる 言語同士を比べるとき、「さくっと作れること」という点では それほど差は出ない。その場合、むしろライブラリの豊富さや デベロッパーの多さなど、外部的な要因が重要になる。 なので、既存のライブラリやサービスをうまく利用して新しいサービスを 素早くローンチする、といった分野では、Lispは相対的には不利であろう。

Lisp(やMLやHaskell)が「仕事として向いている」、つまり競争力を持っているのは、 むしろ複雑度が極めて高く、かつ性能も頑健性も要求されるような 分野ではないか。DBMSとかコンパイラとか VMとかOSとか。というのは複雑度が上がるにつれ 検証の手間というのがどんどん増えてくるので、 目的に合わせた漏れの少ない高度な抽象化と、 メタ情報にアクセスして検証を自動化する手法は 不可欠になってゆくだろうと思うからだ。

(余談だが、この観点では、現在のLispはメタ情報の扱いが弱いと思う。 マクロは強力だが、ローカルなソースコードの表面にしかアクセスできない という欠点がある。つまりプログラム全域を見て演繹できる情報を利用できない。)

もちろん、そういうインフラ系に目を向けるからといって、 Lispの持つ動的な性質を活かさないということではない。 繰り返しになるが「インフラも書けるLL」であるところがポイントなのだ。 高性能で頑健なコンパイラ。でも改良したくなったらちょろっとスクリプトを 忍び込ませることができる。そういうノリである。

Paul Grahamが普通のやつらの上を行けとかもうひとつの未来への道で 「サーバ側で走るプログラムは言語の縛りが無いんだから一番強力な言語を使うべき」 と書いた頃は、一般向けサーバサイドアプリの黎明期であったこともあり、 サーバ側の階層をあまり意識せずひとくくりに論じていた。 10年経って、現実にアプリケーションはサーバ側に移動し、 サーバ側で色々なコンポーネントをどう構成するのが良いかという点に 関心は移っている。 一方で、クライアントマシン側にも計算の一部を振り分けることも一般化してきた。

現代のアプリケーションは、クライアント側とサーバ側に分散した 多数のコンポーネントが協調して動作する、分散プログラムだ。 Paul Grahamは、クライアントサイドのアプリはOSに制約されるために OSのAPIによる言語選択のバイアスを受けるとしたが、例えばクライアントサイドの JavaScriptエンジン、とかゲームスクリプティング、なんてものは OSとはあまり関係ないコンポーネントだったりする。

というわけで現在の環境では、クライアントかサーバか、という分け方よりも、 コンポーネント単位で考えるべきだろう。 独立性が比較的高く、そのコンポーネント内では極めて複雑な処理が必要で、 かつ柔軟に進化してゆくことが望ましいもの。そういうところが狙い目だ。

Tags: , Programming, Lisp