First of all, apologies if I am posting this in the wrong forum, but I thought this one would be the best fit.
I have a simple question. If there would be a new tool for blending animations and setting up behavior, and this was supporting scripting, what scripting language would you prefer it to support?
Some options could be:
Python
Lua
Javascript
Angelscript (similar to C/C++)
Please vote for your preferred scripting language. I would like to take this into account for some software that is in production. It would be great if some people could list their preferred languages in the order from most preferred to least preferred.
Also do you think it would be a good thing to support multiple script languages? Or do you see negative things in that?
All 4 seem to be good pics. I voted for Python, but then again, Iâm biased: Power Python Dev for Maya
Multiple languages is interesting. Maya in essence supports 3+ languages (MEL, Python, API/C++ (plus Python spin-offs, PyMEL, MRV)) and doesnât really suffer for it.
The other advantage of Python is the Facebook affect; i.e.- âgoing where all the people areâ. Python seems to be used by the majority of DCC apps now and therefore youâll get more users familiar with it which allows them to ramp up on the power-usage of your app faster.
Thereâs absolutely no need to support multiple languages- it is more trouble than it is worth, unless you have a damn good reason.
Python is a shoo-in because so many people know it (and it is a good language anyway). The other route you could go, is providing .NET support, and people could use whatever language they choose (including IronPython or IronRuby or F#, for a true scripting/interactive syntax/environment).
[QUOTE=j83;8937]I would advise against having multiple scripting languages in one program.[/QUOTE]
Maya has 2/3 and it works absolutely fine. The only problem is that now I have to give a talk on why 1 is waaaay better than the other. But MEL is still a very soft intro for newbs.
At this point I would still recommend starting with Python 2. Specifically, Python 2.6 or 2.7.
There are lots of third-party extensions that do not have Python 3 support yet. Unless you plan on using zero outside libraries (which would be crazy) youâd probably be a bit early for the party.
If you use 2.6 or 2.7 you can still write nearly everything in Python 3-compatible code, making migrating to 3 easy later. The 2-to-3 tool that comes with it is also magical for converting older code to 3 when the time comes.
[QUOTE=Count_Zr0;8946]Maya has 2/3 and it works absolutely fine.[/QUOTE]
Yes, but that is because of legacy support, not an intentful decision by developers.
The problem is not so much supporting multiple languages, but figuring out how they (and the things they write/do) work together. Which is why I suggested using .NET and the clr, because you are basically working against one language from a setup level (the clr) but can write in many languages.
The only way to do something similar is either to pick one ârealâ code and basically try to compile other code to that (like, try compiling lua to python bytecode?), or basically write something like the clr, in that you define a particular interface everything works against (that interface could be the SDK in which case most of your work would be providing SDK bindings for so many languages).
So, like all things code, anything is possible, it would just be one of the worst possible investments of resources.
About the multiple scripting, do tech-artists often combine elements from different scripts together? Or do you mostly just execute and possibly modify an existing script?
In case of the first, then multiple languages can indeed be a problem.
I guess internally for a company it wouldnt matter, if everyone sticks to the same language.
But I think python is a must, after seeing these results. If this is what most artists are used to, then at least that should be supported, to give it a commercial advantage over other similar software that doesnât use python.
[QUOTE=bjorke;8970]Mel really feels like a fractured conglomeration created by groups that didnât like each other.[/QUOTE]
I feel the same way about certain areas of maxscript- you know certain people implemented certain areas because they follow such absurd conventions and have such different yet consistent classes of problems (and then there are those areas that have just steadily grown because everyone has added things piecemeal, and it shows too).
Buckshag- You should never be modifying an existing script to do something new. You should be writing common code that can be reused, adjusted, etc., and harness for different tasks. It shouldnât be any different than normal programming.
Rob, what I mean is using existing code to use in a new script. For example you might need to do some mathematically complex calculation, that happens to be written and fully battle-tested by someone already. Maybe found on a site like this.
I assume, like in regular programming, that it might sometimes happen that someone would want to just use the part of such script that does this calculation, and use it in their own script they are creating.
But then I guess if that piece of code you would want to reuse is in another language, that you canât use it inside your own script (without converting it). I guess that would be the only disadvantage I could really think of. Or what other reasons would there be against supporting multiple languages?
[QUOTE=bjorke;8970]Mel really feels like a fractured conglomeration created by groups that didnât like each other.[/QUOTE]
This. Also, my experience with the âcommunityâ of MEL scripters has generally been terrible. I started fooling around with LISP at the same time as I was learning MEL, and just asking for help from the communities made me nearly drop MEL in the first week.
[QUOTE=h6x6n;9145]Also, my experience with the âcommunityâ of MEL scripters has generally been terrible. I started fooling around with LISP at the same time as I was learning MEL, and just asking for help from the communities made me nearly drop MEL in the first week.[/QUOTE]
Thatâs probably because most tech artists are pretty terrible programmers. That said, most programmers are pretty terrible programmers, and Iâm not sure the ratio is any different than bad/good TA programmers, but the fact that there are more good programmer programmers than TA programmers often means the programming advice you get will be better in programming community.
