Re[2]: Is Lua the next big thing?

[Lothar Scholz <mailinglists@...>]

Hello Brent,

BF> decision, and right now I am trying to decide the best choice for an
BF> embedding and extension language (for an application written in C++)  
BF> between Lua and Python.

Same here, i decided to support multipe. I'm using a generic interface
that is based on the stack idea of LUA. I'm now able to transparently
use Ruby and Lua for scripting. Python will follow in a week and also
SPider Monkey (Javascript) and ECL (Common-Lisp). I will sell these
plugins for a few dollars as addons. It's not difficult if you do
do it from the beginning. You just need one more indirection object.

I can even mix this languages, so my app can work with Ruby and Python
scripts at the same time.

But this is only possible if you don't need high speed scripting and
have only few objects. But for my apps (see signature) it works
perfect.

BF> My main concern is threading support.  Our application is heavily

I went through this and it costs me a lot of money. I tried python
first, but the whole threading thing is not documented and you will
not get any answers to advanced stuff on comp.lang.python. It keept
crashing and i wasn't able to use pythons charset encodings from
threads. Also python does not scale performance wise on
multiprocessors.

For threading the answer is simple and not satisfying: There is no
really usefull scripting language yet. Python supports it a little bit,
Ruby not at all, Perl is using a fork like modell and TCL is going the
LUA way of complete isolated threads. Complete isolated interpreters
are a problem of its own and simply kills most of the advances of
threading at all. If i have to serialize all data, send it as a byte
stream into another interpreter and deserialize there, i can also live
with serparate processes. I'm not sure if you can migrate a complete
object structure from one interpreter instance to another in LUA (i
don't believe you can).

I think LUA is the best you can get for a multithreaded app, if you
have to design it in a way that multiple threads must be able to
execute scripts.

-- 
 Best regards,                        emailto: scholz at scriptolutions dot com
 Lothar Scholz                        http://www.ruby-ide.com
 CTO Scriptolutions                   Ruby, PHP, Python IDE 's