2011年6月7日火曜日

Common Lispは自由過ぎてわかりづらいという思い

ブログがソースコード貼り付け場所と化しているので、文章を書く努力。推測とか感覚とかなんとなくがミックスされてるので文章としてどうなんだろう。

本文

Common Lispは数多くあるプログラミング言語の中でも、自由度という点では(大量の括弧を気にしなければ)トップクラスの言語ではないかと思います。

例えば、Common Lispには、プログラマが手を加えることのできる処理のタイミングが3つあります。 1つ目は普通に処理が実行される時、2つ目はコンパイル時(マクロ(※1)/コンパイラマクロ)、3つ目は読み込み時です。多くの言語では、2つ目と3つ目の処理に手を加える機能は存在しないか、限定的なものです。

また、Common Lispでは、プログラマが望むならば、大抵のものは自分で作成できます。組み込みのオブジェクトシステム(CLOS)が気にくわなければ、新しいオブジェクトシステムを作成して組み込めます。あるいは、数値演算を中置記法で書く構文を導入することもできますし、正規表現リテラルの記法を定義することもできます。そうして新しい構文や記法を追加しても、Objective-CLになったり、CL++になったりせずに、依然としてCommon Lispのままです。

自由であることは良いことだと、多くの人が思っているでしょう。けれど、Common Lispがこれだけ自由なのは果たして良いことなのでしょうか。

もちろん、良いことです。

良いことですが、世の中にはリスク無しのリターンも、欠点のない利点もほとんど存在しないだろうと思います。なので、このフリーダムっぷりにも相応の欠点がある、と感じています。

なにが問題かというと、それは「わかりにくい」ということです。少ないと言われるCommon Lispのライブラリですが、それでもLispハッカーな方々がいろいろなライブラリを作成し、公開してくれています。そうしたライブラリを使おうとすると、私のような木っ端Lisp使いは思うわけです。「使い方がわからん」と。

というのも、ライブラリごとにインタフェースがまちまち(※2)で、「他のライブラリではこうだったし、たぶんこうだろうな」という考えが通用しにくいからです。もちろん、ドキュメントや、最悪ソースコードをしっかり読めば理解はできるでしょう。しかし、例えばJavaだったらAPI仕様を斜め読みする程度で使い方はわかります。どの機能(クラス)もだいたい同じような使い方だからです。 .NetやPython、Rubyのライブラリも、Common Lispほどわかりづらいことはないだろうと思います。

JavaもC#もPythonもRubyも、おそらくCommon Lispほど自由ではないです。これらの言語を設計した人たちは、プログラマの自由を制限して、思想や作法を強制しています。けれど、そのおかげでわかりやすいです。

上記の言語には、Common Lispよりもたくさんのユーザーと開発者がいます。制限された自由の中で、同じような作法で作られたライブラリ群を使う方が良い、と考える人が大勢いるということだと思います。ならば、そういった考えを貰ってきても良いはずです。うまくいかなかそうでも、Common Lispが消え去るわけではありませんし。

今後しばらく、短い・わかりやすい・再利用しやすい、けれどそのかわりに思想や作法を強制される、という考えでも良いということを念頭にプログラミングしてみようと思います。

自作マクロの山になって本末転倒な予感がしますが。

※1: 仕様上、マクロがコンパイル時に展開される、という表現は正しくないかと思います。詳しくはHyperSpecあたりを参照してください。 ※2: Common Lispのライブラリのインタフェースがまちまちだ、というのは個人的な印象に過ぎないかもしれません。

0 件のコメント:

コメントを投稿