Putting the feelers out there to see what blender users think of access from other scripting languages besides python.
Heres a detailed mail to bf-committers, but posting here since developers have a bias towards their fav language 
http://lists.blender.org/pipermail/bf-committers/2009-February/022669.html
I ask this because it influences how the new Python API accesses blender functionality. If other languages are likely to be added later, its more important to keep the current python api access generic without hand written C/Python functions.
will this limit the power of scripting somehow? or is it just more effort to implement this cleanly?
having support for mono would be kind of nice since then we could use pretty much every language we like. i understand some of the concerns in your cons list though.
@kakapo, I dont think it limits the power of scripting language by using generic access. though there is some speed overhead in converting python arguments to operator properties but I doubt this would be a problem since operators are not designed to be called 1000ās of times a second.
Once Blender 2.5ās Operators are warped you get access to a lot of functionality.
But we still donāt know if ALL function calls will end up wrapped with operators. - calls to draw interface buttons for eg.
Since we already have python calling blender operators its easier if we donāt have to add another method for python to access C functions & auto-generate API docs.
Though some would argue the purpose of operators is not to draw buttons.
You know what I think! 
/Nathan
Iād wager there will probably be enough bugs to root out with the Python implementation (even with auto-wrapping, etc.). Would adding another language really help in that process?
In the long run picture, too, your talking about adding something to potentially fragment the community, which will inevitably lead to debates about which language is best/most powerful (ala the GUI redesign, even though coders tend to be more docile). Perhaps worst case scenario, though. It would definitely make support and maintenance harder, and if whoever implemented the language just disappeared or could no longer maintain it, then youād wind up having to cut the dead weight (bloat) language out of Blender anyways and break more scripts, etc. etc. etc. (probably worst case again).
However, if a language does present significant advantages over Python (beyond coding style; like speed, unavailable modules/features built in, etc.) then it should definitely be considered. Or if it presents a significant boost to the goal of integrating Blender into existing pipelines (I know Perl is used at some more technical places, for instance). If a number of conditions are met that make it viable, there is a long term maintainer, there is enough help in the community, etc. then it would be added. But it should by no means be a willy-nilly process that implements every scripting language out there (which would probably pose some maintenance challenges even for an auto-wrapped API).
+1 from me, I find pythons strict indentation very annoying, and the lack of {} makes the code harder to read.
-1 from me.
I dont know much about this topic, but would it be practical and worthwhile adding support for languages similar to Max Script and MEL? I understand that MEL is similar to Perl, no idea about Max Script. Making it easier for Max and Maya technical artists to migrate over (maybe even making it slightly easier for existing in-house scripts to be converted?) might lower a lot of barriers for adoption of Blender by larger studios.
How about, instead of many, just 1 or 2ā¦ 3 at max.
@jrs100000, maxscript and mel will never happen, these languages are probably not even that good compared to some of the newer opensource scripting languages.
robsta, agree lots are not needed, but even having 1 new language at the moment is a big change from having just py.
A guy named ānuttyā has added LUA to the sequence editor.
http://www-users.cs.umn.edu/~mein/blender/plugins/sequence/luaBlender/readme.txt
Hello,
I vote against other languages.
Better make sure the python implementation in 2.5 is solid, complete and properly maintained than having several - probably (likely) less complete - languages to choose from.
OK - i admit iām a fan of python since i learned it (for Blender). It keeps me like :eek:! Astonishing what is already possible in Blender. Iām just a bit worried about speed - with the current wrapped access to Blender data (like vertex.co) you can write scripts in 2.48 that manipulate meshes with 200k vertices at interactive rates. Hope this will still be possible in 2.5ā¦
So - my opinion: better have one language you can do a lot of things with, than having several languages which can all do the same but only a subset.
Michael
No, it wont be possible but the api will work differently,
Instead of manipulating each verts location, youll set the selection and run the transform operator.
for v in me.verts:
v.co.x += 1
Not exact syntax but something like this
bpy.operator.transform(mode='GRAB', (1,0,0))
For for python functions the logic will be much closer to what the user does, sometimes this is an advantage, other times not.
Though for things like extrude, this is totally insane to code yourself in the existing py api.
Bring them new languages. Would love to see Ruby or even LISP 
Hello
I vote against other languages.
I a newbie to blender but Iāve 20 years of experience in development on computer systems. In my experience the generic API arenāt good. Always in the end you have a ārecommendedā language.
I think is better to have a good language well implemented. By the way Python isnāt my favorite. And I think the time of developers is better use in another improvements to blender.
Regards
Alcides
For me python is the most artist friendly language of the bunch that still makes enough sense to programmers to work with efficiently. Which I would assume is the reason it was picked in the first place.
If the goal of the whole exercise is to force the underlying interface to stay generic - enough to enable people (studios) to easily plug in their own languages - then Iād go with lua. It seems to be the perfect candidate for that, as it is iirc one of the easiest - if not THE easiest - scripting languages to implement. (Not that I would ever want to work with that hideous thing. :p)
No, it wont be possible but the api will work differently,
Instead of manipulating each verts location, youll set the selection and run the transform operator.
Shocked! That will be a huge step backwards - like back to the time before the mesh-module. Or even worseā¦
Operators seem fine for all kind of things no doubt, no discussion - but for something so fundamental like setting the location of a vertex?
Sorry - wrong thread. But this really shocked me and will most likely make me leave scripting for Blender when 2.5 comes out.
From what i hear all my scripts will not be portable to the new system anyway.
Iāll be quiet nowā¦
Greetings, Michael
sorry I should have mentioned you can set the location of a vertex with RNA.
The rna api provides data access but you cant run functions with it.
so you can access them in the same way that you now access vert locations.
Im still not sure how operator and rna-data apiās will sit together though.
Lisp would be nice. It is a good language with interesting features, like metaprogramming.
my vote is -1 for more lenguages, +1 for expert devs choose which language that should be
I have several points to this:
about Michaels complaints- I thought there will be āoperator commandsā, like the transform example, and basic RNA operations also exposed to the scripts. The script itself becomes an operator?I couldnāt see the new api as an step backwards at all. As an artist, I like to think in operations as I would want to do them by hand, and often itās just a way of thinking what is changed, while the result looks and performs similar. Also the advantage of using the scripts as actual parts of blender is huge.
I am also an experienced user of XSI, which supports 2 languages. Itās never been hard to convert scripts from 1 lenguage to the other (Java and Python) but it was a little bit strange, since you often download scripts and want to tweak them. As somebody said, python intendation rules can be annoying and hardly readable(Iād really appreciate vertical tab lines as in KDevelop sometimes, specially with more levels of intendation and longer scripts, or intendation levels collapsing), but this is a minor disadvantage if you think about the huge number of libraries accesible through python, and a decent performance.XSIās āaddonā system is a great great thing(kill me). Each installed script registers an actual ācommandā, which can be triggered with a custom button which you can put into custom panels or link to rigs etcā¦ you can either run the script with clicking the button or do right click -> edit the script. The script commands become a part of the construction history! good thing about addons is you donāt wrap only scripts into them - having the possibility of making actually .blends with some custom data would greatly enhance the distributabilty of advanced scripts, since these often use libraries of pre-made objects(tree generators, city generators, and many others)These scripts are currently not part of blender distribution, which I see as a big problem, since they are extremely useful in production, and not everybody knows blenders forums or the wiki catalogs so well that he can find anything lost in history.
And I forgot to say that I love python. The advantage of keeping it is that itās quite widely used already and especially in blender it has a solid user base.
I generally worry about 1 thing about the switch - will we still have available the nice Mathutils module? I hope so, since I use it very much currently.
Ideasman, thanks for bringing this theme up. There are certainly many interesting brave projects running along with the 2.5 recode - this and bmeshā¦