Like the other people said its a scripting language, and your variable are 
strongly typed ( so what is the point of whining :its normal to be confused 
when to start using something new...)
most of what you said for string manipulation has an equivalent in mel ( 
just need to learn how the docs are organized )

SO yeah its more difficult but you dont need OOp everywhere certainly not 
and at a scripting level ( automation and normal user executing code they 
drag from the script editor...).

A lot of people tend to be lure into aesthetics part of code when its the 
functionality and robustness which matters ( code maintenance and upgrade 
is another beast ).
When you will be a bit more c++ savy you can create your how nodes a 
command to do the actual work i you dont like mel syntax (for other people 
we work together at ilion btw )?

Le vendredi 18 août 2017 17:08:56 UTC-5, Rudi Hammad a écrit :
>
> Hello,
> I recently started a job in a studio that relies only on Mel, where python 
> is officially forbidden to use. I never used mel before. Since I am 
> familiar with C++ it was easy to learn, but still, I would like to share 
> some thought and try to explain 
> why I don´t like it. I only know 3 languages, python, c++ and mel now, so 
> maybe you can shed some light and tell me if my thoughts are wrong or if 
> you agree:
>
> 1-Why do you need to declare the data types in a high level scripting 
> languages? Aren´t data types declaration supposed to help manage memory to 
> optimize your programs? Since mel is high level, do you really need 
> declaring data types?
>  
> 2-the dollar sign before each variable. why? it feels that mel is not 
> smart enough to understand . It needs not only the declaration data type, 
> but also a $ to understand that you are creating a variable. 
>  
> 3-working with strings is excruciating in Mel. In python, since everything 
> is an object you can access all the string methods. .capitalize(), .split() 
> etc... To do simple .split in mel, you have to create a empty array first, 
> then use a proc like tokenize, give it the name to split, where to do the 
> split, and cast it in the empty array, and finally, retrieve the index you 
> need in that array.... in python you simply do somehting like myName = 
> l_myControl_CTR.split("_CTR")[0]...
>
> 4- quote marks to have a variable take a return. so string $myArray[] = 
> `ls -sl`;
>
> 5- no default values on arguments?! you can' t do something like proc 
> myFunc(string $myName="foo", int $default=1)
>
> (6. Also of course not having dictionaries , no external library, no OOP, 
> no access to the API are also big things to consider)
>
>
> My point is not to criticize anyone using Mel. This list is just to help 
> me understand a bit better how scripting languages compare to each other.
> When you work in a studio with a huge Mel legacy you have to get along 
> with it. And I do, I already developed many thing is mel. My only problem 
> is that I am not allowed to use python, but it is what it is.
>
> Anyway, to sum up, for the reasons I exposed above, I find Mel not smart, 
> long, ugly, very painful when it comes to strings, and very limited.
>
> So as I said, my point is not to criticize Mel, but try to understand it a 
> little better. Do you agree with anything I said, or am I just crazy
>
> Thanks,
> R
>

-- 
You received this message because you are subscribed to the Google Groups 
"Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to python_inside_maya+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/python_inside_maya/5c37a29e-ace2-470f-af93-5233240f7509%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to