昨日と一昨日、Franz社と数理システムが主催のLispセミナーイベントで見聞きしたこと。
ただし、セミナーの要約ではなく、Franz社や数理システムの方と直接歓談する機会があって、そのときに伺った話を含めて自分勝手に都合よく解釈したもの。彼らが直接語った言葉ではないので注意してください。


JavaとRDBMSが有用なのは、やっぱり、金銭管理とか人管理とか在庫管理とか注文管理とかスケジュール管理とか、とにかくそういう「エンタープライズ」と呼ばれる領域だけらしい。現在のソフトウェア産業の中心は、その領域におけるソリューションを提供（提唱?）する行為で成り立っている。すくなくとも、そのように見える。そういうソリューションを提供するビジネスが実体以上に過大視されたのが90年代のITバブルで、それを膨らませていたのがJavaであり、RDBMSだった。すでにバブルの本体はしぼんでいる。じゃあ、マッチポンプだったJavaとRDBMSはどこにいったんだろう? もちろん、どこにもいってない。しぼんだとはいえ、エンタープライズな仕事は、未来永劫にわたって確実に存在する。対象はすでにRDB化されてるし、それを扱う技術への需要が減ることはない。安くはなるだろうけど。もうなってるのか。
エンタープライズな領域でのソフトウェア産業のいくすえは、個人的にはどうでもいい。自分がそこで仕事をしていないからどうでもいい、という投げやりな話ではなく、単にどうでもいい。なぜなら、ここで気にかけておくキーワードがあるとしたら、それは「エンタープライズ」ではなく、「領域」のほうだから。エンタープライズは、ソフトウェアによるソリューションを必要とする問題領域のひとつである。つまり、ほかにも問題領域はたくさんあって、バイオインフォマティクス、法律や特許のような知識情報ベース、自律システムのインテリジェントな制御、その他、僕の知らないたくさんの問題領域で、それぞれに問題がゴマンとある。これらの問題に対しては、かならずしもJavaやRDBMSは使えない。正確にいうと、適しているとは限らない。もっと正確にいうと、適していない。
関係を正規化してちょいといじれば解が出てくるような問題でなければ、RDBMSは有効ではない。複雑な構造のデータはツリーで表せることが多いので、たいていはXMLになるだろう。Javaなら、XMLでもライブラリがいっぱいあって便利だね。けど、たくさんの問題領域ごとにツリーは異なるし、既存のライブラリで単刀直入に扱えるようなツリーじゃない場合はどうすればいい? そもそも、その領域で問題を解決する適当なツリーが見当もつかないような場合は? 見知の複雑なデータ構造を暗中模索しながら効率よく開発するようなマネができるのか?
そこでLispですよ。これほどツリーを扱いやすい言語はないし、どんなに複雑な構造のツリーでも言語そのもので容易に扱うことができる。そのデータ構造を扱う処理を含め、どうせみんなS式なので、カットアンドトライで見知の構造に挑むのも辛い仕事じゃない。そして方針さえきまってしまえば、あとはマクロにするなりコンパイルするなりして、さらに開発効率を上げたり、実行速度を突き詰めたりすることができる。さらにLispでは、Prologのような関係プログラミングのテクニックを採り入れることもできる。これは、複雑な関係を内包したデータ構造を扱うのにうれしい（ちなみに、先日発行された "Reasoned Schema" は、一冊まるごと関係プログラミングの話題）。Allegro Common Lispなら、Allegro Prologとして、すでに関係プログラミングの仕組みが用意されてさえいる（セミナーでは感動もののデモを見ることもできた）。
Lispと同じことをJava（やその他の言語）ではできない。できるにしても、超人的な何か（スキルとか忍耐とか偏狭とか）が必要になる。一方、その他の言語にできることはLispにもできる。サポートとかドキュメントとかライブラリの量とか、そういう社会的なメリット/デメリットについても、少なくともACLなら数理システムの技術サポートが得られるし、提供されている機能も多い。また、Lispのドキュメントやライブラリは決して少なくない。解説書も、これからがんばります。とにかく、他の言語にあってLispにないと積極的に言えるメリットはない。この非対象性が、あえてLispを使う理由だと思う。つまり、もはや「なぜ Lisp を使うのか」ではなく、「なぜ Lisp を使わないのか」ってくらい。
最後にもうひとつ、Lispには重要なメリットがある。それは、世界的な標準仕様があること。RubyやPythonのようなスクリプト言語がビジネスとして成功しない最大の理由は、実はこれなのかもしれない。