lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Thu, Nov 25, 1999 at 01:15:47AM -0200, Luiz Henrique de Figueiredo wrote:
> >   Without question Lua is fast enough *as is* for everything I initially
> >expected it to do, and more.  In fact, partly due to its speed I've ended
> >up doing a lot more "inside" Lua than I had originally intended
> That's our experience here at TeCGraf too.
> It's kind of a mental block that needs to be overcome:
>  C is not really needed except to provide services to Lua; a very large
>  part of the application can be written in Lua (it'll get done faster
>  and it'll probably be more nicely coded!).
> [I'd like to hear about other people's experience with this. Please
> post.]

Hmm.. I have an interesting side-spin on this. While certainly Lua is
fast enough to do lots more for me than it's doing now, I have another
reason for leaving some of my code on the "C" side of the
boundary. Typing. Everything in Lua is bound together by ad-hoc
conventions between my C++ code and Lua, and between Lua code and
other Lua code. 

The C/C++ code forms a rigid base which I can feel safe in modifying,
and (more importantly) which can easily be shown to others. It takes
lots of explaining to get others to understand the underlying object
structure and interactions in Lua, since they are all based on
weak-typed conventions. (I even have to explain HOW the inheritence
mechanism works, because I am using a proto-multi-parent model.)

Where I work we use lots of Python code, and we have the same tradeoff
there. Weak-typed languages are incredibly fast to develop in, but as
the systems get large, it's very hard for someone to understand even
small parts by "reading the code". 

FWIW, we've written some new performance scripts and Lua is still
proving to be at least as fast, and sometimes twice as fast as Python.
I'll get the script and results posted ASAP.

David Jeske (N9LCA) + +