MEL in Maya LT rant
polycounter lvl 6
Hi,
This is a rant, so posting here instead of Tech Talk.
Hope someone can prove me wrong, but after using MEL for some days, I am now pretty convinced that MEL is a horrible scripting language, no language I used before even come close, that's including some ancient PHP / Javascript.
Is it true that:
- You cannot breakdown a long script into multiple files without using global procedures (no namespace, no export, all pollution).
- You must structure your script in a way that every reference to a local proc must be defined already. (Note "reference", not "call". It means you have to put shorter, likely helper functions, at the front of script.)
- Once you source a global procedure, it stays there for the entire session. (Impossible to clean up or debug without restart Maya).
- And it's the only language I used that does not have a specification.
I am not going to mention language features, because anyone can tell its lacking...
/rant over
I am curious: Maya LT users, do you use MEL scripts in your daily life? Have you ever attempt to see what's in your MEL script?
This is a rant, so posting here instead of Tech Talk.
Hope someone can prove me wrong, but after using MEL for some days, I am now pretty convinced that MEL is a horrible scripting language, no language I used before even come close, that's including some ancient PHP / Javascript.
Is it true that:
- You cannot breakdown a long script into multiple files without using global procedures (no namespace, no export, all pollution).
- You must structure your script in a way that every reference to a local proc must be defined already. (Note "reference", not "call". It means you have to put shorter, likely helper functions, at the front of script.)
- Once you source a global procedure, it stays there for the entire session. (Impossible to clean up or debug without restart Maya).
- And it's the only language I used that does not have a specification.
I am not going to mention language features, because anyone can tell its lacking...
/rant over
I am curious: Maya LT users, do you use MEL scripts in your daily life? Have you ever attempt to see what's in your MEL script?
Replies
But I am on Maya LT.
http://polycount.com/discussion/190643/mel-mystery-series#latest
And by the way, this language is not limited, it is just confusing as hell.
I've gotten used to the global procedure workflow of it. Just always make sure that your procedure has a very specific name in order to avoid collision with other tools. I've never had an issue with it so far so yeah i think it's mainly an issue of getting used to it.
Dunno if you already did but you should definitely rant on the Autodesk forums and ask for Python support ;-)
Do see my other thread above if you want to double-confirm if it's 100% my fault
My real complain is really global variables. Anything not in the block {} is default global, and they stays forever in the Maya session. So while debugging if you happen to use a global variable by mistake you have to restart Maya or try to overwrite it.
I will get back to you on the refactored Quick Pipe script
Best of luck in your MEL adventure, and can't wait for the Quick Pipe refactored thingy (thanks a lot for that !)
Considering Maya is built on top of it's internal collection of mel scripts...
That mel script's folder and your text editor's find in file function is Maya's secret innards documentation in combination with "echo all commands". I don't know of any scripting language that allows as much unintentional behind the curtains detective possibilities and surgery?
Have you tried leveraging the scope of a variable inside and outside of braces to your advantage?
As far as debugging global variables without restarting Maya...
have you tried find/or mark and copy pasting a debugging naming convention instead of restarting.
Have you leveraged global variables persistence during a session as a utility strategy for all your scripts?
( I have found I am often trying to always do a variation of the same thing when I create a global variable. Enough times that I call a utility script instead now...
that handles global variables "universally" instead of from within whatever tool I am currently working on. Where that tools unique needs may call for extending the utilities features/abilities but hardly ever necessitating that a need to bypass as much with a new global variable from that new script? )