2004/06/26

ちょっと古いけど、 Eric Naggum's rant on C++。むしろすがすがしい程の毒舌ぶり。 Perl版も。

でも、C++もPerlもちゃんと使おうと思えば使えてしまうから、 邪悪性はそんなに高くない。プログラムすることが拷問に等しい、 真に邪悪な言語というものが存在する。 3DオーサリングソフトウェアMayaのスクリプト言語MELがその実例だ。

最近仕事でMayaをまた少し触る羽目になって、忘れていたMELの嫌さを再び 味わうことになった。 前の会社でもMayaを使っていたんだが、思い返せばMaya 1.0betaの頃に MELの仕様に辟易して、 Schemeを代わりに使えるプラグインを開発してそれを使っていたので 汚染されずに済んでいたんだった。

MELという言語、変数が型つきであること以外は、 REPLがあってインタラクティブに評価できるし、 一見良くあるスクリプト言語に見える。

どんな言語にも(Schemeにさえも) 嫌なところ、使っててひっかかるところ はある。MELの「嫌さ」も、最初はそういうものの集積にすぎない、 と思われるかもしれない。 それが言語そのものの質的な欠陥であり、ちょっとした構文や意味の 汚さの問題ではない、というのに気づくのには、しばらくかかる。

最近、その欠陥を表現する一文を思いついた。 MELは、「プログラマによるあらゆる抽象化の試みを拒否する」のだ。

例えば、aggregate typeが基本型(整数、浮動小数点数、文字列)の配列 しかなくて、最初はそれが問題なんじゃないかと感じる。 でも、そのこと自体は、プログラマが自力で構造を配列に エンコードすれば醜くても解決できる。例えば、文字列をデータに持つ ツリーは、整数の配列と文字列の配列をペアで持てばいい。

真の問題は、それを抽象化する手段が無いことだ。ユーザ定義関数は 型つきでなければならず、多相型とかvariantみたいな型が無いため、 「任意のデータを持つ、エンコードされたツリー」を扱う関数が 書けない。高階関数が無いことも、抽象化手段を著しく狭めている。 おかげで似たような関数を目的に合わせて何度も何度も何度も何度も 書く羽目になる。

驚くべきことに、MELはevalを持っているのだ。「万能関数」evalが あれば、大抵の抽象化トリックが実装できそうなものだ。 ところがである。恐ろしいことに、MELではevalの返り値を特定の 型の変数で受けなければならない。つまり、evalの直接のcallerが 「evalが何を返すか」を知っていなければならない。これでは、 他から式を受け取ってそれにevalを適用するような関数を書きようがない。

こういう言語は、何が言語にとって一番重要かを教えてくれる 反面教師にはなる。

Tag: Programming