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.
On Fri, Aug 18, 2017 at 4:15 PM, Justin Israel <[email protected]> wrote: > 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 <[email protected]> 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 > > -- > 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 [email protected]. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/python_inside_maya/CAPGFgA1VvKPmmWSfUecLqUmdb- > UvT4vJPk4EJHJt7mU6MHhVHw%40mail.gmail.com > <https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA1VvKPmmWSfUecLqUmdb-UvT4vJPk4EJHJt7mU6MHhVHw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > 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 -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAP_aC5ZZmx9trd04NDyhLLtd-vPpW%2B62Xz%3DcoymH_kYXVzsEBg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
