2010/02/14

仕事でLispを使うこと

http://www.google.com/buzz/rui314/St7Z3Wm9ZjJ/

Lispはなんとなくすごそうというイメージがあるけど、実際にはそれほどでもない。90年代くらいまではGCがあるというだけで、生産性X倍といえたのかもしれないが、いまは良い他の言語がたくさんあって、言語の日常的な使用例で差が特にあるとは思えない。

[...(中略)...]

Lispで仕事をしたいというのはいいけど、それが極端になってLispでしか仕事をしたくないとかJavaは書きたくないというと、なんかもったいないなと思う。

まったくそのとおり。プログラミング言語なんて道具にすぎない。 エンジニアは仕事に合わせて最適な道具を選ぶのであって、 道具に合わせて仕事を選ぶのではない。

けれども道具に愛着を持つのもまたエンジニアの性であって、 良さげな道具を手に入れたらそれを使ってみたくなるというのも人情だ。

この二つは必ずしも相反するものではない。 自分の得意分野、つまり相対的に自分が他に比べてより多くの価値を生み出せる分野が、 たまたま自分の好きな道具がもっとも適している分野と重なっていれば良い。 もちろん言語の選択には色々な事情が絡んでくるので、 その場合であっても常にLispで仕事ができるというわけではない。 けれども、(1)他ではなかなかできないことをあなたのチームはやれる、 (2)あなたのチームがそれをする時に、Lispを選択すると生産性が最大となる、 というのであれば、Lispを選択しないというのは悪手であろう。

Lispが好きで仕事に使いたいと思っているなら、(2)をクリアするのは簡単だ。 問題は(1)である。他のチームが他の言語を使ってできるのと 同じことを同じように出来るだけでは、意味が無い。 他の条件が同じなら、マイナー言語はメジャー言語より不利なのは間違いない。 エンジニアを探すのも、ライブラリを探すのも、後々のメンテナンスも、メジャー言語を 選んでおいた方が楽になるに決まってる。 よそではできないことができます、そしてその秘密兵器が実はLispなのです、 という順番でなければならない(MLでもHaskellでもいいけれど)。

現在の環境で、そういった意味でのLisp (decentなCommon Lisp処理系)のエッジは、 抽象度の非常に高いところ(DSLとか)から非常に低いところ (ビットを直接触るとかコンパイル結果のネイティブコードを見ながらチューニングするとか) までを単一の言語でカバーしているところだと思う。 今もCommon Lispのコードで共有メモリ上に置かれたバイナリのデータ構造を いじってるのだけれど(事実上、特殊なmalloc/freeを実装している感じ)、 性能を確保しつつメンテナンス可能な範囲に複雑性を収めるには 多分Common LispかC++じゃないと無理だろうなと思う。 とりあえず、それなりの質のネイティブコードを吐けること、 必要ならばさらに高速なネイティブコードを出せるように言語から制御できること、 メモリ上のデータ配置を制御できること、 GCを起こさないコードを書けること、あたりは必須。 (このへんは言語というより処理系の話も含まれるんだけれど、 言語の選択は現在availableな処理系で考えるしかないので、 「そういう処理系が使える」ということ自体はポイントになる)。 それでいて性能クリティカルでないところでは高階関数もGCも使いまくりたいので、 そうなると選択肢はCommon Lispということになる。

JVM上で走るLisp/Scheme処理系というのはその意味で不利な競争を強いられる。 大きな強みである低レベル層へのアクセスが制限されてしまうからだ。 もちろん、JVMはJVMで大きな土俵を用意してるのでその上で競争することにも 意義はあるのだけれど、「他の条件が同じならマイナー言語はマイナーであるだけで 不利になる」というハンディキャップがある。 Clojureのように、今までのメインストリームであまり目にしなかった パラダイムを付加価値として持ち込むという戦略がないと難しいだろう。

なお、Gaucheの狙いは、上で述べたような現行のCommon Lispがカバーするところではなく、 「使い捨てスクリプト」から「大規模なプログラム」へと プログラムが自然に発展してゆけるようにすることにある。

(追記：続きもあるよ)

Tags: Programming, Lisp, Scheme