RE: Is Lua the next big thing?

["Grellier, Thierry" <t-grellier@...>]

A return of experience: one reason why I'm skeptical that Lua can be the
next big thing.

We are running C++ applications with both Lua an Python embedded. 
Lua was initially attractive to replace the configuration text file we
were using. Then we wanted to define through script the behavior of some
C++ application threads (note this are not real threads but coroutines).

We have considered using Lua and Python and selected the later.
It was more painful to embed python, but python was the only one
allowing true reentrance in the interpreter and we needed that, because
we wanted to share the script state between the script threads and not
only through a C++ layer. We haven't seen an easy solution with Lua:
despite it offers coroutines, it doesn't allow to redefine lua_yield()
to have an external control on the lua_resume(). So we were not
confident in having C++ yields combined with lua_resume().
Whereas Python creates a state but offer low level primitives to store
the interpreter state and restore it with a python context switch.
Once python is embedded, this is not any more a pain to embed it. Yes it
is more difficult but not impossible and this entry cost is paid only
once. So now the question is: is it worth keeping lua embedded? Python
also allows redefining access operator to a class member so that it can
become almost as friendly syntax than Lua to reach a configuration
parameter. This cost memory and is not as efficient as Lua. But this was
not an issue there (we are not narrowed to small device with very little
memory).

I guess that dealing with threads isn't an uncommon. With question like:
should I create one lua_State per C++-threads (then isolated, and only
sharing the C++ layer).
or share one lua_State between my C++threads, but then I must let the
interpreter schedule them.
or use pure lua coroutine but only lua can schedule the system.

So when like us we need to share one lua_state between C++ threads, but
with giving to the lua code the possibility to call a C++ wait() and not
lua_yield(), we are in trouble. And python can here fill the gap.

This is maybe one too specific problem, but giving that other languages
already matured (more or less elegantly also because they may favor
quick solutions to long waits to maturation) on a lot of issues, I guess
that not selecting them is probably not that wise. Because the added
value of Lua is maybe not that significant in the project context. Speed
is probably not that important. Because lack of speed just shows a bad
partitioning between script side and compiled side.

But I admit that I would like to use more Lua because of its elegance.


-----Original Message-----
From: lua-bounces@bazar2.conectiva.com.br
[mailto:lua-bounces@bazar2.conectiva.com.br] On Behalf Of Zach Dwiel
Sent: Thursday, March 08, 2007 6:03 AM
To: Lua list
Subject: Re: Is Lua the next big thing?

I like it.

On 3/7/07, therandthem <therandthem@yahoo.com> wrote:
> Yes.
>
> ;)
>
> ----- Original Message ----
> From: Mark Hamburg <mhamburg@adobe.com>
> To: Lua list <lua@bazar2.conectiva.com.br>
> Sent: Wednesday, March 7, 2007 11:55:04 AM
> Subject: Is Lua the next big thing?
>
> http://rc3.org/2007/03/is_lua_the_next.php
>
>
>
>
>
>
>
>
>
________________________________________________________________________
____________
> It's here! Your new message!
> Get new email alerts with the free Yahoo! Toolbar.
> http://tools.search.yahoo.com/toolbar/features/mail/
>


-- 
--
dwiel.net