some Mel toughts

[Rudi Hammad]

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

[Ravi Jagannadhan]

This could become a circle jerk, it's not "bad", just different. And old.

"There are no dumb questions" - Carl Sagan.

--
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_m...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/dfdf1274-b376-4dad-91f6-e9df52edd2de%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Justin Israel]

The main thing to keep in mind is that Mel is a DSL; intended for a specific purpose as an expression language for Maya. It isn't a general purpose language. Many of the questions you ask are simply just language design decisions that probably took into consideration the goal of the language and balancing the complexity of the implementation of that language. 

Python is a general purpose language so it makes sense for it to have many more constructs in order to develop larger applications and libraries. 

On Sat, Aug 19, 2017, 10:08 AM Rudi Hammad <rudih...@gmail.com> wrote:

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?

Mel is not the first language to do this. See Perl (strict mode) as one example. The intention is to prevent mistakes by declaring variables up front. 

 
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.

Again, look at many other languages that do this. Perl, php, shell languages. Just a language designed decision which probably includes how parsing works. 

 
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]...

Yes that is a shame it can't be as simple for doing string manipulation. Mel has to be compiled to be executed in the C++ space (as far as I know). So without developing a more complex language, it may have to keep it simple for the interpretation. 

4- quote marks to have a variable take a return. so string $myArray[] = `ls -sl`;

Bash has a similar concept to use backticks to evaluate one expression and use its results in another expression. Perl has a similar concept that executes the expression in a subprocess and returns results. 

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)

Again, just a balance of the complexity of the language vs being the goal of an domain specific expression language. 

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.

I would be interested in know why there is a blanket rule forbidding python. But I also understand if they are deeply engrained with legacy Mel. 

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.

There isn't much to be said here really. It's not worth it to try and defend one or the other in a battle of languages (on this forum). Python clearly has more complexity and serves a wider goal than Mel. And Mel was born from someone's experience with previous languages and had a smaller goal. 

As for making a case for your company to change its mind, that would require knowing their full reason. And then you have to prove that there would be an improvement to productivity and to integration with external libraries. One can also show that Mel and Python can still call into each other to some degree. 

Justin 

[Kenneth Ibrahim]

In addition to Justin's spot on responses I believe that MEL is in some part modeled after a language called Sofia which was the scripting language for the legacy Dynamation product.

Justin 

--
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+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA1VvKPmmWSfUecLqUmdb-UvT4vJPk4EJHJt7mU6MHhVHw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

"God is a metaphor for a mystery that absolutely transcends all human categories of thought. It's as simple as that!" - Joseph Campbell

[Rudi Hammad]

circle jerk...i googled that to see what it means...I wish I didn´t

Thanks for answering point by point my questions Justin.
The studio is doing great with relying on mel, so I have adapted to their needs. I guess in the end, wether you like it or not,  you work with what you have.
They told me they have 10 millions lines of code in mel, so it is impossible to go back. I wonder if it is possible that the reason why they have 10 millions lines of code is precisely because it is mel

ps: sorry for the offtopic, I know it is not python related, but I thought it would be interesting.

[Justin Israel]

On Sat, Aug 19, 2017, 12:06 PM Rudi Hammad <rudih...@gmail.com> wrote:

circle jerk...i googled that to see what it means...I wish I didn´t

Thanks for answering point by point my questions Justin.
The studio is doing great with relying on mel, so I have adapted to their needs. I guess in the end, wether you like it or not,  you work with what you have.
They told me they have 10 millions lines of code in mel, so it is impossible to go back. I wonder if it is possible that the reason why they have 10 millions lines of code is precisely because it is mel

I get that they have 10 million lines of working legacy Mel. Although I still don't know why that justifies that they need to move forward in Mel-only development. One can still call the legacy Mel from python. It would be interesting to find out what they have found to be problematic with introducing Python. I don't think any of those 10 million lines need to be rewrittten necessarily. Going back isn't really required if you can successfully write production python that interfaces just fine. 

ps: sorry for the offtopic, I know it is not python related, but I thought it would be interesting.

It's Maya related, which is a topic for this forum. 

--
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_m...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/1080bff3-2b6f-4315-9682-2db55ee377ed%40googlegroups.com.

[Rudi Hammad]

I get that they have 10 million lines of working legacy Mel. Although I still don't know why that justifies that they need to move forward in Mel-only development. One can still call the legacy Mel from python. It would be interesting to find out what they have found to be problematic with introducing Python. I don't think any of those 10 million lines need to be rewrittten necessarily. Going back isn't really required if you can successfully write production python that interfaces just fine. 

Yes, that is exactly what I thought too. I asked if I can call their mel  from python, but they don´t want to mix script languages in a pipeline that has been working great for years just with mel. Also not everyone knows python so...

What this means is that the mel library will keep growing.

[Cedric Bazillou]

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 )?

[yury nedelin]

I am curious , why not python ?

Yury

--

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+unsub...@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.