Lua vs Python?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Lua vs Python?

Mike Fahl
I'm investigating scripting languages, and both Lua and Python seem to
potentially fit the bill more or less. They have many things in common.
Both appear to be "free" (including commercial use), more or less object
oriented, extensible, embeddable, byte-code interpreted, etc.

Python appears to have better support for some OO concepts, (eg multiple
inheritance and class data members). I seems to support multithreading
on some platforms. The strict reference-counting memory management
scheme seem to be more "time-predictable" than the mark-and-sweep method
used in Lua. Python also appears to be a more widely supported and used
language.

Lua has tag methods, which seem to make it easier to layer it on top of
existing "legacy" objects, while still being able to access those
objects almost as if they were part of the language. OTOH, adding
support for multi-threading seems to be non-trivial, and hits from the
GC could be an issue in rea-time applications.

Any opinions or comparisions of these two languages would be greatly
appreciated.

Mike Fahl

Reply | Threaded
Open this post in threaded view
|

Re: Lua vs Python?

Lyn A Headley
my two cents:

first of all, Lua's not object-oriented (right?).  One could easily
_make_ it object oriented, but then again one could add garbage
collection to C.  It all depends on how convenient it is to do.

anyway, I've some experience with both languages, and here's my
comparison:

Lua is smaller, simpler, and faster than Python.
Python has _tons_ of libraries of extremely useful code written for
it. Lua has relatively fewer.
Both are easy to interface to C.

Both languages are excellent embedded languages (the two best, IMHO).
I think it boils down to whether you feel you need the extra builtin
functionality provided by Python.  If not, I'd go with Lua for its
speed and elegance.


-Lyn


Reply | Threaded
Open this post in threaded view
|

RE: Lua vs Python?

Bret Mogilefsky
In reply to this post by Mike Fahl

> Python appears to have better support for some OO concepts, (eg
> multiple
> inheritance and class data members). 
> [Bret Mogilefsky]  I haven't got much experience with Python, but Lua
> supports both of the above, though multiple inheritance takes a tiny
> bit more coding than the single inheritance demonstrated in the docs.
> 

Reply | Threaded
Open this post in threaded view
|

Re: Lua vs Python?

Mike Fahl
In reply to this post by Lyn A Headley
Lyn A Headley wrote:

> first of all, Lua's not object-oriented (right?).  

Agreed. However, by storing method pointers into "fields" and using the
fallback mechanism, it can be made to behave in a way that is pretty
close to OO.

> Both languages are excellent embedded languages (the two best, IMHO).
> I think it boils down to whether you feel you need the extra builtin
> functionality provided by Python.  If not, I'd go with Lua for its
> speed and elegance.

Point well taken. Exactly the kind of feedback I was looking for. The
speed issue is certainly of importance in my case. 

My primary problem with LUA as it seems right now is that I'd like to
use it in a multi-threaded way, based on OS-supported threads. I assume
all it would take to do this is to collect all the globals used by LUA
(ie, its C-language implementation globals - not the LUA globals) into a
structure which can then be "instantiated" to get a new, fresh LUA
interpreter which I then can stick into a thread and run on its own. I
brought this up a while back on this mailing list, and that seemed to be
the general consensus as I recall.

Mike Fahl

Reply | Threaded
Open this post in threaded view
|

Re: Lua vs Python?

Luiz Henrique de Figueiredo
In reply to this post by Mike Fahl
>My primary problem with LUA as it seems right now is that I'd like to
>use it in a multi-threaded way, based on OS-supported threads. I assume
>all it would take to do this is to collect all the globals used by LUA
>(ie, its C-language implementation globals - not the LUA globals) into a
>structure which can then be "instantiated" to get a new, fresh LUA
>interpreter which I then can stick into a thread and run on its own. I
>brought this up a while back on this mailing list, and that seemed to be
>the general consensus as I recall.

We've decided to add this functionality in the next version.
Keep tuned.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: Lua vs Python?

Russell Y. Webb
In reply to this post by Mike Fahl
> My primary problem with LUA as it seems right now is that I'd like to
> use it in a multi-threaded way, based on OS-supported threads. I assume
> all it would take to do this is to collect all the globals used by LUA
> (ie, its C-language implementation globals - not the LUA globals) into a
> structure which can then be "instantiated" to get a new, fresh LUA
> interpreter which I then can stick into a thread and run on its own. I
> brought this up a while back on this mailing list, and that seemed to be
> the general consensus as I recall.

I'd like to multi-thread Lua too.  I was thinking of making a fallback 
that maps the undefined table called "thread" to a different table for 
each thread.  So one could write, thread.x, in any thread and get a private 
version or write, x, to get a global.  The problems I see with this 
scheme are some overhead and one needs to prevent threads from 
defining a global called "thread" (which I'm not sure how to do).

Any comments?

Russ Webb