2011/11/13

言語の比較

「関数型言語はなぜ流行らないのか」ってネタがまた流行ってるようで、 それについては特にコメントは無いのだけれど、 「関数型言語のメリットが(オブジェクト指向言語に比べて)わからない」って 言っているエントリがあって、その思考ステップが、 ちょっと引っかかりやすい落とし穴かもしれないと思った。

機能単位で「できること」を比べても意味がない

あなたが良く知っている言語をαとしよう。そして、比較したい言語をωとする。 一部の信者はωを最強言語だと奉っているようだ。良く知らないで批評するのは アンフェアなので、あなたもωを使ってみて、ひととおり書けるようになった。 それでもなお、信者の主張するωの利点というのがピンと来ない。なぜなら、

1. 「ωで出来るすごいこと」は「αでもできる」か、「αでも頑張ればできる」
2. 「αで簡単にできること」が「ωでは簡単でないように見える」

1から、ωの採用にはメリットが無く、2からωの採用にはデメリットがあることが言える。 従ってωを使う意味はない。

理屈は通っているように見えるけど、実際の言語の進化史と比べてみると、 妙な齟齬がある。というのは、より良い後発の言語が、先行する言語に出来たことを わざと「出来なくしている」ケースがよくあるのだ。

手続き型言語ではほとんどの場合、手続きの入り口は一つだけ、戻り値も 一つのものが多い。アセンブリ言語では入り口がいくつもあったり、 複数の戻り値を持つ手続きを書けるし、それは便利に使えてた。 似たようなことを例えばCでやろうとすると不格好でオーバヘッドも大きくなる。

構造化プログラミングはgotoを排除すべしと言った。gotoで簡単に出来たことが、 純粋な構造化プログラミングではひどく不格好になる。

純粋関数型言語では状態の変更を禁じているため、状態変化を表現しようとすると モナドだの何だのと面倒くさい手段を取らないとならない。

なぜ、後発のパラダイムが「出来ること」を少なくしようとするのだろう。 少なくとも歴史の前半について、多くのプログラマは答えを何となく知っているだろう。 とすれば、その理由を外挿して考えられないか。出来ないことは、 別の見方をすればメリットなのかもしれない。単に「より良い方法」があるだけかもしれない。(e.g. gotoは、クロージャとTCOがある言語なら、関数呼び出しでより安全に、効率を落とさず実現できる。)

そして1については、結局チューリング完全な言語同士なら 「頑張れば」の程度問題になってしまうのだ。 少しだけ冗長になるけどαでも書ける。ライブラリを使えば簡単に書ける。 プリプロセッサを使えば、IDEを使えば… 等々。

もちろん高級言語で10万行のプログラムをアセンブリ言語で書こうと言い出せば、 「そりゃ頑張ればできるかもしれんけど、頑張る意味あるの?」ってことになるから、 どっかに閾値はあるはずだ。その閾値は何で決まるんだろう。

不満を比べてみたらどうか

私はLispがベストだと思っているけれど、その「ベスト」には特定のニュアンスがある。 私が言うのは、"Lisp is the language that sucks least." ということだ。 どんな言語にも使ってて「クソだこの仕様」と思うことはある。 Lispにだって山ほどある。そこらじゅうクソだらけでいつも文句たらたら使っている。 けれども他と比べた時、最も「クソの度合い」が少ないのが、私にとってはLispなのだ。

地上に出ている輝く山の高さを比べたら、どの言語もどんぐりの背比べなんである。 得意分野によって山の場所が違うだけだ。 けれど、山以外の場所の沼の深さを比べてみたらどうだろうか。

沼が無い言語なんて存在しない。100年後はどうなっているかわからないけれど、 今ある言語なんてどれもぐちゃぐちゃの沼だらけ、良く知られた山を離れたとたん ずぶずぶと足がめり込む湿地帯が広がっている。

これは多分に主観だ。だから、あなたが今使っている言語で全く不満を感じていないなら、 多分それがあなたにとってベストな言語なんだろう。どんな素晴らしい言語を持ってきても、 あなたを説得することは不可能だ。だってωに出来ることは (1)αでもちょっとだけ頑張れば できるか (2)αでうんと頑張ればできるけど、そもそもそんなに頑張ってやる必要性を感じない、 わけだし (後者のポイントで必要性を感じていたなら、あなたはαに既に不満を持っているはずだ)。 一方で、αで簡単にできたのにωでは出来なくなっている機能がきっとある。

だから、「αよりωが良い」と言えるのは、 「αに感じている具体的な不満がωでは解消されていて、それが「出来なくなったこと」を補って余りある」と感じられた時だ。

あなたが言語に感じる不満は、「あなたがプログラミングで実現したい世界」と 「その言語で容易に表現できる世界」とのギャップだ。不満を感じていないということは、 言語がものすごくパワフルでどんな世界も容易に表現できてしまうってことかもしれないけれど、 あるいは「あなたが、その言語で容易に表現できる世界しか見ていない」ということかもしれない。

それに、二つの世界の間に多少ギャップがあっても、慣れるにつれ沼の位置がわかってきて 無意識のうちに避けて通るようになる。その沼をうんと遠回りして迂回することが 当然に思えて、もしそこに橋がかかっていたらどれだけ楽になるかってことに なかなか気づけない。

現在の業界を見渡して、「今業界で扱ってる問題については、言語αで十分だよ」と 言うことはできるだろうけれど、「業界は、言語αで十分対応できるような問題しか扱っていない」 とも言える。だって扱い切れないような問題は、コストが見合わないからね。

もちろん、言語αで十分な解くべき問題というのはたくさんあるから、 それを解くことにも大いに意義がある。今、言語αでは沼が深すぎて届かないような 問題というのは、ごく特殊な領域の前線だけの話かもしれない。けれども、今の前線基地は、 10年後か20年後には立派な高速道路が通る大きな街になるかもしれない。

だから、言語ωのメリットを考えるには、今の主流のパラダイムでは 限界を越えてしまうような問題を考えてみる、ってのも一つの方法だ。

次の世代が手にする道具

沼の回避方法を熟知したベテランプログラマなら、ちょいと野心を出せば、 うまく湿地帯を回避しながら前線まで進むことはできるだろう。 これまでもプログラミングは「そういうもの」であったわけだし。

けれど、今まさにコンピュータにさわり始めた若い世代は、多分沼だらけの 湿地帯を泥にまみれて進むのはまっぴらだと思うだろう。 少しでもより整備されて、前線に速く到達できる道具があれば、そっちを選ぶだろう。

より良い言語を使いたいという欲求は、不満の大きさに比例するはずだ。

どこに不満を感じるかは、何を対象としているかで違ってくるだろうから、 そこで「自分の推す言語」はそれぞれ違ってくると思う。 けれど、今使っている言語にさほど不満を感じてないなら、 言語の優劣を議論することは多分できないんじゃないかな。

昔は皆アセンブリ言語で書いていたけれど、今全てアセンブリ言語で書けと言われたら 不満だらけでやってられないだろう。もっと書きやすい方法を知っているし、 扱う問題も規模もはるかに大きくなっている。 ならば、将来の世代は、言語αで書けと言われたら「やってられないよ」と言うだろうと 考えるのが自然だ。もちろん、その時彼らはωも不満だらけで使ってないかもしれない。 けれども、将来彼らが使うかもしれない言語Xから 逆算してみることで、 今ある言語のメリットを比較することもできるだろう。

Tags: Programmin, Lisp