What are your general opinions on binding scripting languages?

[Corman]

What are your general opinions on binding scripting languages? I know this can turn into a heated debate on what scripting language is better or what feature one has over the other, but I am not looking for this. I am finalizing a draft for an artical and would like to get other ideas from people. I have my own personal feelings on this topic but want to get a good sampling from a larger group. So what are your general problems, concerns, quarals, beefs, pains, etc. with scripting languages and binding compiled functions with that scripting language? I am trying to get answers on a general level as well as trying to see if there is a basic converging opinion on this subject. Thanks for any contributions to my research that you may be able to provide.

-Corman

[Sharkbait]

I have my own particular preference (Angelscript), but the following are some aspects I consider when looking for a scripting language, in no particular order:


Size - may be important for downloadable software
Ease of embedding
Speed
Ease of host function / class / variable integration
Syntax - is it easy / familiar from the script writer's point of view
Features - co-routines, object orientation etc.

[Corman]

Thanks for your post, and all very valid. I am pretty sure that everyone would have these things to say. I am more so looking at scripting languages as a whole. For example something I am looking for is; "As a whole it is missing X, Y, and Z..." (even though 10% of them may have it). I am trying to find the overal frustrations and what things are lacking. Does writing proxies and hooks drive you crazy, and why? Do you wish you can call compiled code without doing so, even if it was a tool? These are the sort of questions I am looking to see answered. I know this may all sound vauge, but it is ment to be so on some level to get an unguided responce on the general questions of binding scripting languages. Thanks again, and I am looking forward to more insightful posts.

-Corman

[illume]

C++ is really anoying because of different compiler versions breaking the ABI. It is also anoying because apis tend to be more complex to wrap.

C libraries are generally really easy to bind.

Dynamic binding of DLLs is great. This means you can write the binding in a scripting language. eg. ctypes and pyobjc for python.

gccxml can make generating bindings automatically easier by spitting out xml of the what it parses.

swig is a great mature tool that supports generating bindings for many different languages.


--
making games, making web (http://renesd.blogspot.com/)

[Corman]

Thanks for bringing up the point of dynamic binding of DLLs. What I am going to talk about might be different that what you were meening, but it sparked a thought/memory, so thanks. What would be the general thought about using PE .edata (export table) for binding functions. Just "exporting" a regular function(s), and having a system that the EXE scans itself and autobinds the functions, and the same with loading and scanning DLLs. It would keep a function database, all you would have to do is just call the function from the script, it then captures this, checks and converts the data into proper formats, pushes them onto the stack, and just calls the function from the function database. I know of such a system and the theories, but what are the general thoughts on this. Would you find this really helpful? What would be your primary concerns and thoughts against using such a system? Does it sound too complicated that you wouldn't even try using it, even if the functionality was provided to you with no additional work on your part? Basically this meens no writing of binding code, hooks, or wrappers with no preprossesing or extra files to complie. I am trying to stay scripting language agnostic here. Thanks, and keep them rolling in.

-Corman

[Nikster]

I use scripts in virtually all my apps, they're good for debugging if nothing else. I mainly used Lua in the past but have been toying with giving AngelScript a look in, the main reasons these two are on the top of my list are

a) the syntax, which for me is important as I'd rather not spend time getting used to a new syntax as it's time consuming.
b) the ability to call native code, so it means you can have your script handling dll's and the like.

The main use of Lua I used last was to save my projects using anonymous tables for a WYSIWYG editor for a game, it was a blessing as multiple people could work on the same project and the anonymous tabling was good to use for merging projects (source control style) I'm not sure this would have worked to well with other scripts I am familiar with.

I really think you need to look at the problems you need to solve then choose a script which is most suited to those problems, I also tried my hand at SMALL, which is a nice small scrpiting language oddly enough :) but it's not well suited to big applications and certainly not games imo.


PS:- on the note of auto exporting functions, this can be dangerous especially if things like IO are accesible via script.. you have to consider security implications.

[Corman]

Yes security is always an issue, but that is part of planning and design of any project. If you do not what end users using file IO, you don't export it. This hypothetical system does not auto export every thing, only what you flag with say a BINDTHIS macro (say basically a __declspec(dllexport)). But then there is the case were you want to export functions for other reasons than just for the auto bind system, maybe there would be naming rules that would not bind these exported functions to the scripting language. I understand there are many special cases and many different scenarios.

-Corman

[Sharkbait]

Now that puts the question into a better context :)

The major issue with emdedded scripting languages seems to be integration with the host application. A lot of scripting languages seem to offer integration of host funcitons only and require development of wrapper functions to push parameters in and out of the scripting engine's stack - case in point: LUA.

This is where my bias in favour of AngelScript comes in: AS allows you register functions, types (classes) natively without the need of wrapper functions. To be more precise, AS supports various calling conventions, ranging from c declarations all to the way to a 'maximum compatibility mode' that is essentually LUA's stack pushing / popping.

Another reason for my bias towards AS is that it is a C++ style syntax. This is really a subjective aspect however as the target audience may prefer a 'softer' script like LUA.

For the record, I have experimented only with LUA, TCL, Python and AS so this may not be the most imformed post, but I hope you find it helpful.

[mot]

Boost.Python wins for me. It works both ways, which means that it is
possible to create DLLs written in C++ and make them accessible from
standard python scripts, or embed python into C++ applications.

It works without preprocessing, so the bindings are not generated by
a program, but instead they are a part of the C++ compile.

It is actually possible to create a class in C++ then inherit from it in python and then inherit from it back in C++.

It just works... I don't know what more anyone could wish for.

As for the cons, I don't think there are any. The runtime size is not negligible
but it can be compressed, that's been discussed before in other threads I
think.

[chrisroyale]

I'm also an AngelScript fan.

Because a lot of my classes are auto-generated by my tools I have automated the registration of classes and member functions with the script engine and they become 'available' to the scripts automatically. There is still the abstraction/VM layer between the game code and the script but by compiling to byte-code the additional performance problems with interpretation are removed.

Something which hasn't yet been mentioned is the difficulty in debugging scripted code. This essentially requires an IDE of sorts to be written, though to an extent I suppose it could be achieved less elegantly in a console window. There have also been various releases of AngelScript and it's an ongoing project itself, so there are often problems which are outside of your control.