PDA

View Full Version : Alternative scripting languages



MentalFish
09-26-2007, 06:28 PM
If you could choose an alternative scripting language to Lscript, which one of these (or others) would you prefer?

Lightwolf
09-27-2007, 01:46 AM
I'm very fond of Lua, but Python is making it as the industry standard now.

Then again, if SWIG (http://www.swig.org/) would be used to hook up the scripting, you could make almost any language work.

Cheers,
Mike

jin choung
09-27-2007, 02:16 AM
yah, maya blender and truespace (if that one really counts) are the ones i know of that are python friendly now.

i'm not hip on what the benefits are... apparently in maya, there are hooks and stuff into the os that are accessible through python... but personally, i just want a language that i can pick up a book on and read about how to do something....

it would make whatever programming you pick up in lw more widely applicable too which is always nice.

jin

Lightwolf
09-27-2007, 03:02 AM
yah, maya blender and truespace (if that one really counts) are the ones i know of that are python friendly now.

Add Fusion, XSI (with a bit of manual installation), Houdini, RealFlow, the next release of Nuke...

Cheers,
Mike

StereoMike
09-27-2007, 08:09 AM
Why the manual installation in xsi? I thought it comes with the package?
mike

kmacphail
09-27-2007, 11:54 AM
Let's add Massive and Qube to the list.

With so many companies in the industry choosing one common scripting language it certainly makes developing a pipeline that much easier. Integrating Python into Lightwave would be a great benefit, and if this can be done via SWIG as Mike suggests then so much the better.

-Kevin

Lightwolf
09-27-2007, 12:13 PM
Why the manual installation in xsi? I thought it comes with the package?
Maybe it does now (XSI supports a number of languages) - I just found an XSI Wiki entry when I checked before posting BS ;)

Cheers,
Mike

MentalFish
09-28-2007, 12:54 AM
A wrapper to make it language independent would be great, as I am still scared of python and its "define-the-scope-by-indentation". I love bracket based languages. As long as the syntax is valid, it can easily be auto formatted by the press of a button (the way it is done in Flash).

I don't see JavaScript in SWIG's list of supported languages... hmmm

Class based JavaScript (JS2.0/AS3.0/ECMA4/Tamarin or whatever you want to call it) is something I would really like to have in LW. I am definately not wishing for a prototyping based JS1.4 solution, with all its lacking debugging capabilities and easily messy code.


Tamarin is a free virtual machine and just in time compiler intended to implement the fourth edition of the ECMAScript standard, commonly referred to as JavaScript 2.

Tamarin was initially developed by Adobe Systems for its ActionScript Virtual Machine (AVM) used in Flash 9 and up. The code was donated to the Mozilla project on November 7, 2006.[1] The contributed code is tri-licensed under the GPL, LGPL, and MPL and will continue to be developed in Mozilla CVS, as the rest of Mozilla source code.[2]

The contributed code is approximately 135,000 lines of code[3] making it the largest single donation of code to Mozilla project besides Netscape itself.[4]

Tamarin will be part of Mozilla 2[5] (and therefore part of Firefox). The project to integrate Tamarin and SpiderMonkey is called ActionMonkey. [6] [7]

Tamarin will also continue to be used in the future versions of Flash.

http://en.wikipedia.org/wiki/Tamarin_(JIT)

MentalFish
09-28-2007, 01:11 AM
I guess there is a trend of Python being used in "rendered" graphics, while class based JS is a trend in interactive media -> Flash, Unity3D, future version of Director and PIM (both using spidermonkey -> which will become class based in the coming releases). As Winnie the Pooh says, "both please", or better, "all please".

MentalFish
09-28-2007, 01:20 AM
A little sneak peek of how AS3.0 looks like:

The class script:

package ca.flashdev.hello {
public class HelloWorld {
public function sayHello():String {
var greeting:String = "Hello World!";
return greeting;
}
}
}

An instance the HelloWorld object:

import ca.flashdev.hello.HelloWorld;
var classInstance:HelloWorld = new HelloWorld();

http://www.flashdev.ca/article/hello-world/

Btw, why is there a 5 min edit limit on posts in this forum?

Lightwolf
09-28-2007, 01:34 AM
I don't see JavaScript in SWIG's list of supported languages... hmmm

There is SwigJS.

As for AS3... I don't really see any advantage in that to be honest. If a SWIG based approach makes it easy to add a few languages then I'd rather see that then yet another exocitx language and nothing else (as is AS3 in the CG world).

I'm not much of a Python fan either, but since it is becoming the de facto standard in CGI apps, it makes a lot of sense to support it.

Cheers,
Mike

MentalFish
09-28-2007, 02:15 AM
As for AS3... I don't really see any advantage in that to be honest. If a SWIG based approach makes it easy to add a few languages then I'd rather see that then yet another exocitx language and nothing else (as is AS3 in the CG world).

Agree on the part "another exocitx language" being a bad idea, but with Adobe pushing alot of resources into it, keeping it open source, making it the next JavaScript engine for Firefox and so on, it isnt a weird one-off language, its basically the implementation of ECMAScript4 and is close to identical to regular Java and C# as far as syntax goes.

As you say, Python is becoming more and more the standard or allready is the standard in the graphics industry, and also if its possible making LW language independent, even better (including class based JS/AS:)).

My reason for using LightWave is because I need content in my Flash and ShockWave3D projects, and with Poetry In Motion using Mozilla's SpiderMonkey, I am surrounded by JavaScript ( class based ECMA script ). So in the interactive / realtime 3D industry the story is totally different from the "rendered 3D" side of the industry. And since I am using JS in PIM, it would be nice to just keep on going in the same manner when making scripts for LW.

But I do agree, locking the scripting to just one language is a less desirable than giving the user a set of choices. That goes for anything in the application really, pop-up windows or docked windows, icons or text ( or both)...

adamredwoods
09-28-2007, 10:33 PM
I prefer scripts to be scripts. I guess anyone would do.

But I always want the option to go in-depth to get more power with a C/C++ SDK.

papou
09-29-2007, 07:11 AM
i hope PIM will be release before to add a new language in it.
little OT here, but most of us are looking for the previewing capacity before the interactive java mocap export to games exe htlm magic and expensive parts...

Red_Oddity
09-29-2007, 08:10 AM
I actually like the language MEL is based on (PERL i believe), it's very easy to understand and read, errors are very easily identified and it is bracket based and uses semicolumns to end a line.

I find it works much better for me than say python (though python has an insane amount of online reusable code), i simply hate the way that indentations are what makes or breaks a script (it can take hours to find an error just because you've been coding a bit sloppy and forget to tab indent a line...ofcourse, the whole indentation was one of the goals of Python to make sure people write readable and clean code, but how often do you see that happening in real life.)

Anyhoo, i'll still take any of the two, that and/or a overhaul and complete integration of LScript (yes, that includes being able to write expression and runtime code within Layout and Modeler itself with LScript.)

Lightwolf
09-29-2007, 08:12 AM
I actually like the language MEL is based on (PERL i believe), it's very easy to understand and read, errors are very easily identified and it is bracket based and uses semicolumns to end a line.

It is Tc based, which is more of a shell scripting language than anything else.

And to be honest, having scripted in MEL for the past two weeks.... :thumbsdow :compbeati 8/ :foreheads

Cheers,
Mike

Red_Oddity
09-29-2007, 08:23 AM
You hate it that much Mike?
I'm no programmer, but i have written a pretty big amount of tools for Maya.
Tools that recreate the way the camera works in LW, custom multi selection connection editors, exporters, importers, render and Fusion comp dispatchers, automated workflow and repeated task tools, multi selection renaming tool (with it's own expression functions and adheres hierarchies) you name it.

I thought it was a whole lot clearer than LScript (could also be because MEL can and is bascially tied into every part of Maya and it is very wel documented)

Anyway, anything is better i guess than what we have right now, a very limted undocumented barely implemented programming language.

Lightwolf
09-29-2007, 09:02 AM
You hate it that much Mike?
As a programming language and implementation of one? Yes, at least. It is so... 80ies.


I thought it was a whole lot clearer than LScript (could also be because MEL can and is bascially tied into every part of Maya and it is very wel documented)
Extremely well tied in, no doubt. I like the openess, but not the way it has been accomplished.
As for the documentation... well, it has its flaws as well. This is one reason why I'd like to see a standard programming language coupled with a clear API that interfaces with LW.
That way you can learn the actual language (and in the case of Python re-use that knowledge) and NT "only" need to document the API.
I.e. looking at the LW SDK: It doesn't teach you C, it requires you to know C. The same should go for a scripting language.

Anyway, anything is better i guess than what we have right now, a very limted undocumented barely implemented programming language.
No doubt, but since it would need to be redone one way or the other, it may as well be redone use more current paradigms. (also, to do this properly I suspec it would break the C SDK and this plugins completely as well as a side effect - sooner or later).

Cheers,
Mike

evenflcw
09-29-2007, 09:45 AM
I don't know Python and I'm surprised that it "define-the-scope-by-indentation". That does sound bad. I'm keen to think this is a way to make it look simpler (no odd symbols) to non-programmers but that just doesn't sound very flexible or reliable for more advanced scripts.

I wouldn't mind perl. From what I've heard it seems to be quite elegant and capable. I don't mind Lscript that much either, although objects and maybe some stronger typing would be nice at times.

I question why people need a different scripting language. LScript is easy to learn. Is it not just the case that people are having problem with LWs structure and the "Lscript SDK" rather than the syntax?

Lightwolf
09-29-2007, 10:00 AM
I don't know Python and I'm surprised that it "define-the-scope-by-indentation". That does sound bad. I'm keen to think this is a way to make it look simpler (no odd symbols) to non-programmers but that just doesn't sound very flexible or reliable for more advanced scripts.
Well, that's something I have no problem with really. I mean, all of my code looks like that anyhow, regardless of the language.
And Python has grown to be a de-facto standard.
Just imagine how plugin devlopers would whine if LW was based on... Modula-2, or even Objective-C.

I question why people need a different scripting language. LScript is easy to learn. Is it not just the case that people are having problem with LWs structure and the "Lscript SDK" rather than the syntax?
Well, we currently have the main problem of the LW architecture not being open enough.
And since this will require changes, they might as well use a scripting language that is in wider use. The nice thing is that some of them even allow you to import libraries. I.e. hook up an SQL database with your scripts. Powerful stuff that is, and you draw on a wealth of add-ons and code that is out there.

Cheers,
Mike

faulknermano
09-29-2007, 11:20 AM
I actually like the language MEL is based on (PERL i believe), it's very easy to understand and read, errors are very easily identified and it is bracket based and uses semicolumns to end a line.


in my eyes, essentially, MEL and LScript is very much the same aside from certain "calls" to global functions that's internal in Maya. it was a more or less pleasant learning transition coming from LScript.



Anyhoo, i'll still take any of the two, that and/or a overhaul and complete integration of LScript (yes, that includes being able to write expression and runtime code within Layout and Modeler itself with LScript.)

same. i also script in Javascript for after effects stuff and i dont really care so much of the language as the host application's SDK and how the end-scriptwriter can actually manipulate data within.

LightFreeze
09-29-2007, 12:19 PM
Python for me, its simple to pick up, its a lot more powerful than you first think, there`s stacks of modules you can pull in for expansion and the indentation thing seemed strange at first but you soon realise it works well.

Red_Oddity
09-29-2007, 04:43 PM
As a programming language and implementation of one? Yes, at least. It is so... 80ies.

Extremely well tied in, no doubt. I like the openess, but not the way it has been accomplished.
As for the documentation... well, it has its flaws as well. This is one reason why I'd like to see a standard programming language coupled with a clear API that interfaces with LW.
That way you can learn the actual language (and in the case of Python re-use that knowledge) and NT "only" need to document the API.
I.e. looking at the LW SDK: It doesn't teach you C, it requires you to know C. The same should go for a scripting language.

No doubt, but since it would need to be redone one way or the other, it may as well be redone use more current paradigms. (also, to do this properly I suspec it would break the C SDK and this plugins completely as well as a side effect - sooner or later).

Cheers,
Mike
Yes, i can see where you are going with this, i agree with you completely on the Python part and on second thought wouldn't mind seeing this implemented as the language and most available libraries and 3rd party programs are very well documented, the only thing i would have to learn is the custom commands that LW would require (as one would with learning the Maya MEL commands) and the way Python handles end of lines (which shouldn't be too big a problem as i write most of my code in SciTe, which does auto indenting (come to think of it, the problem with the indenting always happens in Maya's command editor on my part, as it is a pretty bad implementation of a script editor))

As for LW and it's plugins breaking? I seriously wouldn't mind it busting LW completely and forcing the programmers to rewrite the whole thing from the ground up.
I seriously for one haven't understood why they didn't do this in the first place.
Break open all the old code, go by it feature by feature so it can be build in such a way that every input and output are open to the SDK, connect the same feature/plugins data to an undo/redo stack that works universaly and tie it all to an internal scripting language that has access from within Layout to it all aswell (when doing this one could even build the undo redo stack out of those text based script commands, catch two birds with one stone sorta speak).
I know this sounds like a grand task (and i'm sure it is much much grander in scope than i describe), but i think it is the only way to go, sure you probably break some interoperatability between plugins, but hey, so far LW is hit and mis program when it comes to stuff like that anyway (just go count the amount of different interfaces, layouts, structures and work aproaches that have cluttered up Layout so far already.)

So far the whole parallel make over has still left us with a program that isn't that well suited for larger crew projects with a dependency on a custom pipeline (i know, i know, it sounds very unfair to all the hardwork the folks at NT have done so far, it's not all black and white, but at the moment LW on the grander software scale still hasn't gotten further than what it had to offer with the LW 7 update..there is a reason why so many people have switched over to XSI and Maya, while still keeping LW for the fun, old skool feel or as a hobby tool at home.)

anyhoo, my post is getting waaaaay longer than the first 3 lines i had in mind, i'm off, it's sunday morning afterall by now.

habaņero
09-30-2007, 01:50 PM
Swig sounds like the perfect solution. I am pretty confident that learning javascript, ruby or python would be a much softer learning curve than Lscript given the state of its documentation, feature holes and/or bugs.

MentalFish
09-30-2007, 07:07 PM
i hope PIM will be release before to add a new language in it.

PIM is using SpiderMonkey, so when SpiderMonkey gets an update in 2008 (and a new name ActionMonkey), PIM will "automatically" have class based, object oriented, JavaScript syntax, unlike the current version of SiderMonkey which is JavaScript 1.4 with prototyping as the only way of handling "OOP".

So PIM, Director and Firefox will have access to OOP, bracket and class based syntax in 2008, while Flash and Unity3D both allready have this.

Like Lightwolf has mentioned, it seems like a SWIG type solution would be the best, so we could have both Python and others. But if SWIG in effect excludes the possibility of using SpiderMonkey, then ofcourse it wouldnt support one of the best script engines available, both in terms of development speed and pure processing speed. Perhaps it could be possible to take some of the SwigJS code and update it for SpiderMonkey and the future version of it called ActionMonkey.

adamredwoods
10-08-2007, 11:47 PM
Has anyone heard of the D programming language?

I've looked it over, seems pretty intuitive (as far as programming goes) and did not seem that it would be too difficult to port the Lightwave SDK over for it. To me it seems to be a cross of lscript and C, so you could get the best of both worlds.

My unknowns for the language would be:
- stability
- MAC OS shared libraries

Pluses are:
- cross platform compiler to native code
- speed (vs interpreted)
- garbage collection

Check it out:
http://www.digitalmars.com/d/

Lightwolf
10-09-2007, 02:21 AM
Has anyone heard of the D programming language?

The problem is that it is compiled, except for the garbage collector you might as well use C/C++ now.
Getting the SDK to work is easy... porting it to be proper D would take a long time.

And, as a compiled language it won't allow you to develop as quickly, which is the whole point for scripts (otherwise there'd be no need for scripting at all).

Cheers,
Mike

adamredwoods
10-09-2007, 01:35 PM
Good points.

I do seem to fall back to lscript just to test ideas before compiling to C.

jin choung
10-09-2007, 10:41 PM
It is so... 80ies.



as a non-programmer, i LOOOOOOOOOOVE this aspect of mel.

it is essentially the same concept as windows 3.1... ALL (and i mean all) gui functions simply issue DOS (mel) commands.

it sounds so backwards but in a production environment, it makes so much sense.

just the fact that i can easily record what the heck is going on when i press a button has led me to be able to very quickly and even thoughtlessly string together simple commands to create quick scripts when i need them.

if the advantage of a scripting language is to be more nimble than a compiled language, it is really really really hard to beat mel and its implementation.

fault it as you will but as a non-programmer, i've never seens ANY other 3d graphics package give you that much access with this much ease. and i can't frankly imagine a better way to do it.

one thing i wish for is that the whole UTILITY NODES become a full featured node driven programming language and come out from under the shadow of shading utilities already. nevermind getting a seat in the back in hypershade... there needs to be a HYPERNODES window or something. i suppose it already IS a capable programming utility but it needs things like ease of construction (ability to easily drop in an intervening node into the stream and quicker connection facility).

i think it was you that commented on a distaste for the maya environment before... just gotta say, man, i disagree.

jin

Lightwolf
10-10-2007, 02:06 AM
as a non-programmer, i LOOOOOOOOOOVE this aspect of mel.

it is essentially the same concept as windows 3.1... ALL (and i mean all) gui functions simply issue DOS (mel) commands.

Erm, but Win 3.1 never worked as you describe...


just the fact that i can easily record what the heck is going on when i press a button has led me to be able to very quickly and even thoughtlessly string together simple commands to create quick scripts when i need them.

But you could do that with any other system as well...


fault it as you will but as a non-programmer, i've never seens ANY other 3d graphics package give you that much access with this much ease. and i can't frankly imagine a better way to do it.
Hard to tell for me, I haven't played much with the other, but MEL surely is a scary experience. If that truly is the best out there.... :oye:


i think it was you that commented on a distaste for the maya environment before... just gotta say, man, i disagree.

That's allright, we can agree on disagreeing :D

I'm just as picky about code as I am about gfx, and Mel is f'ugly ;)

Cheers,
Mike

jin choung
10-10-2007, 02:29 AM
win 3.1 was not just riding on top of dos? i always just thought of it that way....

anyhoo, yah. i'm fine with agreeing on disagreeing... and on this point regarding mel, i do. and strongly.

jin

jin choung
10-10-2007, 02:37 AM
But you could do that with any other system as well...


if so, i've never seen it done in another graphics package. have you? where every conceivable operation can be echoed as a command that can be executed from a command line or simple script?

the fact that EVERY gui function is just executing mel means that i can replicate exactly the effect that i want, down to the parameter, setting, etc.

anyhoo, if that's hell for a graphics programmer, that's unfortunate. but for cg production generalists or TDs, it's heaven.

jin

Lightwolf
10-10-2007, 02:40 AM
win 3.1 was not just riding on top of dos? i always just thought of it that way....

It was sitting on top of DOS (which, even though very primitive, was an OS and not a bunch of commands), but it wasn't a GUI driving DOS commands.

Cheers,
Mike

Lightwolf
10-10-2007, 02:42 AM
if so, i've never seen it done in another graphics package. have you? where every conceivable operation can be echoed as a command that can be executed from a command line or simple script?

Except for modo, not, but that's becuase I didn't have to code for any of them.
I think XSI is quite similar as far as commands are concerned, but I've only looked at the SDK in depth, not the scripting.

I will do and get back to you :D (which reminds me I could check out Houdini again...)

Cheers,
Mike

dsol
10-10-2007, 06:26 AM
I've voted for Javascript 2/Tamarin. Firstly, because I know it pretty well already from using Flash and After Effects (and I'd like to get my teeth into Unity at some point too!). Secondly, on a more personal note - I prefer the syntax, at least compared to Python. Though maybe if I got more into it, it'd make more sense.

Of course, to echo everyone else - SWIG would be perfect, best of both worlds etc. :)

An interesting observation made in this thread is that JS2/Tamarin is widely used in the Interactive world, while Python is dominant in the Rendering world. I don't know if that's a coincidence or if JS2 is genuinely better suited for writing complex real-time interactivity. If so, let me say that I think it's very likely that the future of all 3D apps is going to be about more interactivity, agent/behaviour based design etc. As 3D content becomes more complex and user-guided procedural synthesis becomes a necessary tool to populate and animate these complex scenes, it would be useful to have a future-proof scripting language which can support this evolution.

Lightwolf
10-10-2007, 06:29 AM
An interesting observation made in this thread is that JS2/Tamarin is widely used in the Interactive world, while Python is dominant in the Rendering world..
I used to think so... until I found out that most of the OLPC (http://laptop.org/) project uses Python as well - for interactive applications. And we're talking low cost, slow hardware here.

Cheers,
Mike

Steamthrower
10-10-2007, 09:42 AM
I voted for Javascript since it, along with Actionscript, is a language I heavily use. To me it's simpler and more intuitive than Python or Lua. Even though I know multiple programming languages I still hate doing anything with them, however. The less stress the better, at least for me.

stib
10-23-2007, 06:13 AM
Wimps! I vote for LISP (http://xkcd.com/224/)!