邪悪言語MEL

たまたまみつけてしまいました。
Gaucheの開発者Shiroさんのブログより。

プログラムすることが拷問に等しい、真に邪悪な言語というものが存在する。 3DオーサリングソフトウェアMayaのスクリプト言語MELがその実例だ。

邪悪な言語wwwwwww
ものすごい言い様ですwww

MELは、「プログラマによるあらゆる抽象化の試みを拒否する」のだ。

同意ですね。
そもそもMELは抽象化なんて考えないデザイナー、というところをターゲットにした言語だとおもわれます。
そしてその仕様こそがMELがこれだけ広く使われるようになった理由かもしれません。
が、その仕様もShiroさんほどのハッカーの方には不満以外何も無いでしょうね。。

おかげで似たような関数を目的に合わせて何度も何度も何度も何度も書く羽目になる。

なりますwwwwwwwwwwwwwwwwwww
もうそういうもんだと思って書いてましたねー。
だから他の言語、僕の場合大きかったのはActionScript2.0でしたが、オブジェクトが作れる喜びってのはすごかったです。
そもそも最初は何も意味がわかりませんでしたけど、オブジェクトとかww
なのでMELからその他の言語にいくときはものすごい苦労するんじゃないかと思います。
僕は相当苦労しました。。

そもそもMELは全て文字列で扱う言語なので、オブジェクトが返ってくるよ、とかいわれてもスフィアがなんだって??ぐらいに思ってしまってましたww
配列以上のものが扱えないし、イメージできないww

でも僕は逆にMELのすごいところはその切り捨て方だと思ってます。
Shiroさんみたいな言語作っちゃいます系の超一流ハッカーにしてみたらそりゃ邪悪言語だと思います。
ただMELの設計者も、抽象化だの何だのを良く知ったプログラマだったと思います。
なのにこの切り捨て方!!
僕が同じ立場で言語の開発やれって言われたら、恐ろしくてこんなに切れない。
ぶーぶー言われるに違いないし、そもそもこんなものが作りたく無い、とか思っちゃいます。
そういう意味では非常に評価んじゃないかと。びっくりするほどほど潔い。
ビジネス的にやりました!って感じが出てます(ホントか?)

なのでMELは邪悪な言語ではもありつつも、Maya使いのスクリプト開発の敷居をとことん押し下げたという功績も持ってると思います。
間違いなく、他のソフトよりも開発スキルの無いデザイナーが気軽に触ってる。
Maxscriptとか、やれることはかなりMELより多いし動的片付けだったと思いますが、ぺーぺーにはいろいろ難しかった、、、

まぁそういう割にはバッククオートでの評価とか、変数名に$が必要とか、若干シンプルじゃないような気もする部分はありますし、好評価な部分はそんなにないんですが
ってか良く考えたらJavascriptとかつけといた方が随分良かったかもね、と今更。
あれならクラスも作れるし、高階関数も使える。それに動的型付けだし。
今みたいにJavascriptが活発だったらもっと違う方向にも行ってたかもねー。

ってフォローしてみましたけど、今後UIを伴った100行そこそこ以上のツールを書こうと思ったら、MELは間違いなく使いませんwwwwwwwwwwwww
もうちょいPythonとのバインディングが整備されてくれるとより嬉しいんですが、まぁMELよりはずっといいです。
言語自体が天と地ほどの・・・w

今後は独自言語なんか作らんでPythonくっつけた方が、ユーザーも企業も嬉しいこと尽くめだと思うので、こういう邪悪言語は生まれなくなってくるんじゃないかと思います。
ユーザーもわかりやすくて、MELなんか作るよりもずーっといいですね:)

Maya 1.0betaの頃に MELの仕様に辟易して、 Schemeを代わりに使えるプラグインを開発してそれを使っていたので

何それすげぇwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
まだ1.0のBetaだというのにSchemeのバインディングwwwwwwwwwwwwww
恐るべしwwwwwwwwwwwwww
興味本位ながら使ってみたいwwwwwwwwwwwwwwwwwwwwwww

以上、邪悪言語のフォローと批判でしたwwww
一応4年も使った訳だし、ある程度フォローしとかなきゃアレですwwwwwwwww

「邪悪言語MEL」への12件のフィードバック

  1. MELは腐ってますよねえ.
    あんなに文字列に依存した言語なのに,文字列処理の関数群があまりにも貧弱過ぎ.
    Pythonが使えるようになってからはoneliner以外もう使わなくなりました.
    PythonだとOpenMayaも混ぜて使えるし,ステキです.

  2. evalのネストを使えば…

    string $rawcmd;
    proc f(string $type)
    {
    $cmd = $type + ” $retval[] = `” + $rawcmd + “`”;
    print $rawcmd;
    eval($cmd);
    print $retval;
    }

    $rawcmd = “ls -l”;
    f(“string”);

    // Error: print $retval; //
    // Error: Line 8.15: “$retval” is an undeclared variable. //

    んーだめか。
    因にN88Basicはローカル変数が使えなかったんでローカル変数の使えるFortran大学で使い始めた時には感動しましたw。

  3. >オブジェクトが返ってくるよ、とかいわれてもスフィアがなんだって??ぐらいに思ってしまってましたww

    (笑)

    でもこれで閃いた。そう、Mayaではオブジェクトとはノードなんだよ!だから「オブジェクト」を作るのはAPIの役目なんだ。

    てことなんすかね。

  4. やはり反響がデカいwww

    >ますおさん
    > あんなに文字列に依存した言語なのに,文字列処理の関数群があまりにも貧弱過ぎ.
    ですねwwwww
    結局似たような文字列処理の関数ばっかり書いてるとかになってしまいますw

    > PythonだとOpenMayaも混ぜて使えるし,ステキです.
    OpenMayaだとMObjectを渡す必要があったりするのが、若干面倒だなとは思いつつ、自分の応用次第でいろいろと融通が利くのは嬉しい限りです。
    まだOpenMayaと一緒くたに使って、とかはやってないので、もうちょい上手く使えないかなーと模索中です

    >hohehohe2さん
    おー、面白そうなことを!
    でも実用性は若干謎な気も・・・ww

    > 因にN88Basicはローカル変数が使えなかったんでローカル変数の使えるFortran大学で使い始めた時には感動しましたw。
    Fortran大学、、、じゃないですね、すみませんwwwwww
    ローカル変数がないとはまたハードボイルドなw
    全部グローバルだといろいろ面倒くさそうというか、イライラしそうですw

    >hajimeさん
    > そう、Mayaではオブジェクトとはノードなんだよ!だから「オブジェクト」を作るのはAPIの役目なんだ。
    そう!前に思ったことがありました。
    Mayaでオブジェクト指向もどきやろうとするならノード作って値を格納だ!と。
    でも超貧弱な構造体もどきしか作れないな、と気づいて止めましたww
    そもそもそんな危険なことは出来んなとwwwwww

  5. 自分に取って、MEL(Maya)の面白いところは、シーンファイルであるmaファイルがMELそのものであることにあると思います。

    つまり、シーンやGUIなど全ての内部状態をMEL以外の形式に頼らずにMELコマンドの羅列だけでシリアライズ・デシリアライズできることがmaya(MEL)を設計・実装する上で重要なコンセプトとして掲げられているのだと推測しています。

    そのため、人がプログラミングをすることを第一の意義に置いた一般的なプログラミング言語が重視している抽象化やコードの記述性・柔軟性といった豊かさは二の次であり、(比較的大きなコードでも)上から単純に逐次実行していく上で無理のないパフォーマンスを出す形態をベースに、一般的なプログラミング言語の要素である、分岐や変数という要素を付けた感じに捉えています。

    また、MELはある意味でUnixのシェル(sh)にも似ています。文法もそうですが、ある時は組み込みのインタラクティブ・シェルとして振る舞い、またある時はスクリプト言語を処理するインタプリタ言語として振る舞うところに似た印象を受けます。

    まぁともかく、SchemeとMELをSchemeが得意・コンセプトとする領域で評価するとMELがかわいそうな気がします…。

  6. んー、俺程度で意見を言うのもなんですが、MELがなかったらプログラム自体に興味が持てなかったし、他の言語は理解してもらう気があるのか疑問に思うぐらい複雑だと思います。
    理解力が足りないと言われればそれまでですが…。

    MELはMayaユーザーの為の言語として考えれば十分意味があると思いますし、非常にわかりやすい言語だと思います。
    確かにMayaがないMELはゴミみたいなものですが、Maya+MELで評価しないとフェアじゃない気がします。

  7. やー、みなさんのご意見興味深い。
    ありがとうございます。

    >mynzさん
    maの存在を忘れていました:P

    確かにmaはMELのサブセットというか、限定されたコマンドを実行してMayaのシーンを復元することが出来るようになっていますね。

    これは僕も非常に好きな点で、プログラミング言語という側面ではない、ある種のマークアップ言語のような性質、と感じています。
    構成要素をリファレンスで読むような数行のma書いてレンダリング用のマスターシーン作ったり出来るのは非常に便利です。

    MayaとMELは切り離せないもので、ただのプログラミング言語、って見解だけでMELを見るのは違うのかも、ですねー。

    >Co,さん
    > MELがなかったらプログラム自体に興味が持てなかったし、
    そう!そこはすごく重要な点だと思います。
    僕もMELから入ったようなものなので、やったことがダイレクトに返ってくる心地よさというか、そういうものは鮮明に覚えてます。
    出来るだけ敷居を下げることでより多くのユーザーにそんな体験をさせられるようにはなっているのかも、と思います。
    最初にMaxScript触れって言われたら相当キツかっただろうなぁ、、、

    やはりMELは良くも悪くも、デザイナーのための言語、という気がします。

  8. 私はもうMELを4年くらい触っていないので、今はもっとましになっているかもしれません。以降は私の知る範囲でのMELについての話です。

    前いた会社はMayaの初期のbetaの頃から大口ユーザだったので、かなり色々要望を出していくつかは採り入れてもらいました。evalについても、APIレベルでは戻り値の型が動的に取れるようになったので、プラグインと併せればそれなりに柔軟には書けるようになりました。最初はAPIレベルでも、評価される式の結果の型を知っていないと値が取り出せなかったのです。それだとユーザから受け取った式を評価して結果を返す、みたいなコードが書けないので、例えばMayaのコマンドウィンドウ(でしたっけ? MEL式を打ち込んで評価できる環境)の代替物をプラグインで書くことができませんね。文句ばかり言っていたのでMELチームには嫌われていたかもしれません。

    中の人の話では、そもそもスクリプティング言語の候補としてMEL(の原型 – 確かWavefrontのdynamationが起原だったような気がしますが、はっきりとは覚えていません)とSchemeとが挙げられていたそうです。で、実際に両方を実装してみて、性能の点でMELに軍配が上がったとか。もちろん設計上の決定というのはいくつもの要因が絡むので、それだけが決定要因だったわけではないと思いますが。ちなみに私の書いたSchemeプラグインとで性能測定をしたところ、やっぱり数値演算ではMELにかなわず、しかしシーングラフを辿ってノードを次々処理してゆく、みたいなケースではほぼ同等かSchemeの方が若干良い、という感じでした (Schemeはグラフ処理は強いですから。MELだといちいち配列にして回さないとならないので)。ただ、MELの数値計算のアドバンテージについては、動的言語でも型推論やJITが普及してきた現在においては薄れていると思います。

    mynzさんのコメントについてですが、シーンファイルがスクリプト言語そのものであることはMELに特有の話ではありません。私はシーンファイルにSchemeそのものを使ったこともあります (Cf. http://practical-scheme.net/docs/ILC2002.pdf )。もっとも、デザイナやTDに書いてもらうにはSchemeの括弧は抵抗が大きいと思うので、MayaがMELではない言語を採用することになったとしても、生のSchemeよりはもっと主流よりの構文を用意していた可能性は高いと思います。その意味ではPythonは良い位置(言語的強力さと構文の親しみやすさ)を備えていて、現在のCG界であれだけ使われているのはわかる気がします。

    MELのShellライクな構文にはそれなりに便利なのですが、そっちの方面では既にTclが同様の構文を用い、構文とセマンティクスの一貫性に優れた設計を示していました。MELはdynamation的な静的型の演算向けの構文/セマンティクスと、Shellの動的/インタラクティブな用途向けの構文/セマンティクスを両方採り入れようとして、Tclが示していた一貫性を却って失ってしまい、どちらにも中途半端になっていたように感じました。何というか、惜しい感じなんですよね。ちゃんとやりたい方向は向いていて、どうにか仕事をこなすことはできるんだけれど、もう少しだけ頑張ってたらもっとはるかに楽に多くのことが出来ただろうにな、という意味で。

  9. すごい反響ですねぇ
    プログラムがっちりやったあとに
    MELに入った自分としては
    MEL=バッチファイル的
    (シェルともいえますが)な感覚で使ってますねぇ

    開発言語の選択ってプログラムの規模とか
    性質で選択したりするんで

    小さめのはMEL
    ちょっと大きめなのはPython
    速度が要求されるのはC

    みたいな使い分けすれば
    MEL自体の言語仕様が貧弱としても
    まだまだ使えるのかもとか

    まぁ個人的には
    MELの文字列処理が不満なのと
    Pythonのfor文がお気に入りなので
    Pythonメインで行きたいですけどねぇ

  10. まぁ、色々と不満はありつつも、これまで苦楽を共にして積み上げてきたもんがあるんで、ちょっとした処理はちゃちゃっとMELで書いちゃう自分がいるんですけどね(笑)

    本当はPythonで書きたいけど、うちまだ7.0だからなぁ・・・

  11. 昨日家帰って即書こうと思ったんですが、具合が悪くてすぐにぶっ倒れました。
    遅くなってごめんなさい。

    >Shiroさん
    ご、ご本人・・・!!
    非常に恐縮です。。。
    コメントありがとうございます!

    > 私はもうMELを4年くらい触っていないので、今はもっとましになっているかもしれません。

    僕は逆にMELを触り始めて4年ぐらいなのですが、記憶に大きな変更というのは無いです。
    おそらくShiroさんが触られていた頃から変わっていないと思います。

    > 前いた会社はMayaの初期のbetaの頃から大口ユーザだったので、かなり色々要望を出していくつかは採り入れてもらいました。

    かつての上司が「前いた会社」の人だったので、その辺はいろいろ聞いていますw

    > evalについても、APIレベルでは戻り値の型が動的に取れるようになったので、プラグインと併せればそれなりに柔軟には書けるようになりました。それだとユーザから受け取った式を評価して結果を返す、みたいなコードが書けないので、例えばMayaのコマンドウィンドウ(でしたっけ? MEL式を打ち込んで評価できる環境)の代替物をプラグインで書くことができませんね。

    なるほど。プラグインからもevalが出来るんですね。
    っていきなり低レベルな返しをしてすみませんwww
    それが出来るようになったことでSchemeバインディングのプラグインが開発出来た、ってことなんでしょうか。

    Schemeが初期のスクリプトの候補だったというのは非常に驚きです。
    MELの起源に関してはDynamationが元にあった、ということであればまぁ納得いく範疇なんですが、Schemeはどうしてなんですかね。
    もしや内部に熱心なSchemerが・・・?ww

    でも
    > Schemeはグラフ処理は強いですから。
    ここでなんとなく納得できました。
    Mayaの中ではグラフがぐっちゃぐちゃに絡み合うこともしばしばで、その辺の処理がやりやすいなら確かに候補にも挙がりますよね。

    > 私はシーンファイルにSchemeそのものを使ったこともあります

    !!
    これは非常に興味深いです。
    英語は全くわかりませんが頑張ってpdf読んでみたいと思います。

    > もっとも、デザイナやTDに書いてもらうにはSchemeの括弧は抵抗が大きいと思うので、

    僕が最初にSchemeのコードを見た時、確かに括弧に目がいったのですが、ちょっと勉強してみるとその考え方が手続き型言語とはまるで異なることに衝撃を受けました。

    Pythonが好まれる理由は、MELからの移行が比較的行いやすいというところもあると思います。

    ここでSchemeがくっつきました、といわれても、何それ??でしょうし、今までの考え方との差異が大きすぎるため、勉強しないといけないものがすごく多くなるので(長期的にはそれもありだと思うのですが)、おそらく避けたがる人は多かっただろうなと思います。

    > その意味ではPythonは良い位置(言語的強力さと構文の親しみやすさ)を備えていて、現在のCG界であれだけ使われているのはわかる気がします。

    はい、大変重宝していますww

    > MELのShellライクな構文にはそれなりに便利なのですが、そっちの方面では既にTclが同様の構文を用い、構文とセマンティクスの一貫性に優れた設計を示していました。
    > Tclが示していた一貫性を却って失ってしまい、どちらにも中途半端になっていたように感じました。

    Tclは触ったことがないのでわからないのですが、当時から存在するアプリケーションではTclをサポートしていたりしますよね。
    そこともやはり関係あるんでしょうか。

    > 何というか、惜しい感じなんですよね。ちゃんとやりたい方向は向いていて、どうにか仕事をこなすことはできるんだけれど、もう少しだけ頑張ってたらもっとはるかに楽に多くのことが出来ただろうにな、という意味で。

    確かに仕事は出来るし、3Dアプリケーションの言語として最小限必要な機能は備えていると思います。
    そしてデザイナーが触りやすい構造になっているとも思います。

    楽をする、といわれると、個人的にはとりあえず動的型付けと高階関数、あとは構造体的なものが作れる仕組みがほしかったですね。
    ってそれ言うとほとんどPythonなんですがwww

    いやー、非常に勉強になりました。
    ありがとうございます!

  12. >@hさん
    > MEL=バッチファイル的
    > (シェルともいえますが)な感覚で使ってますねぇ
    多分mynzさんが挙げられていたシーンファイルに絡んだりしてるんじゃないかと。

    > 小さめのはMEL
    > ちょっと大きめなのはPython
    > 速度が要求されるのはC
    そんな感じかなと思います。
    ちっちゃいスクリプトなのにいちいちパスの説明とかするのも面倒ですし、、
    C++で書くのは個人的にはノードが必要!とかMaya都合でどうしても、ってところぐらいかなぁと思います。
    7,8割はもうPythonでいいかなと。

    > MEL自体の言語仕様が貧弱としても
    > まだまだ使えるのかもとか
    使える、というかMayaはまだMELべったりなので、どちらかというと使わざるを得ない、ぐらいな気がします。

    >ぷーとんさん
    > これまで苦楽を共にして積み上げてきたもんがあるんで
    僕もこれは少なからずありますwww
    なので不満はありつつも愛着がないわけではないというか、、
    や、貧弱なのはわかってるんです、これから積極的に使いたいとかでもないんです。でも、、、みたいなwww

    > 本当はPythonで書きたいけど、うちまだ7.0だからなぁ・・・
    Pythonいいっすよwww
    是非www

コメントを残す

メールアドレスが公開されることはありません。