邪悪言語MEL

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

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。

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

(笑)

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

てことなんすかね。

やはり反響がデカいｗｗｗ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

私はもう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が示していた一貫性を却って失ってしまい、どちらにも中途半端になっていたように感じました。何というか、惜しい感じなんですよね。ちゃんとやりたい方向は向いていて、どうにか仕事をこなすことはできるんだけれど、もう少しだけ頑張ってたらもっとはるかに楽に多くのことが出来ただろうにな、という意味で。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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