Lua Strengths/Weaknesses and usage info

[David Jeske <jeske@...>]

On Tue, May 15, 2001 at 09:23:31PM -0300, Luiz Henrique de Figueiredo wrote:
> What is your experience?

I'll summarize at the top and save people time. This isn't all
positive towards Lua, but it's all good information. Of course this is
all in my humble personal opinion.

Lua's biggest strengths are:

 - ease of integration (the lua C api is simple and powerful)
 - execution speed     (the lua VM is very fast)

The biggest troubles I've had using Lua are:

 - using my add-in class machinery is very error prone because 
   the syntax is all based on tables and functions.

   (anyone have any good syntax for classes??)

 - combination of add-in class machinery and weak typing makes
   my Lua code hard to understand and makes errors hard to
   report about and thus hard to track down.

I (obviously) wouldn't have either of those problems if I were using
Lua for some simple configuration and simple scripting like it's
sort-of intended.

Ironically, the part of a project where I did use Lua as a simple
configuration language basically had a form of "type checking" built
in so that I could give specific errors when lines of the
configuration were invalid before trying to startup the program. (I
did this by overriding setglobal) It was just too troublesome when an
invalid script setting would just cause some random error at runtime.

------ and now onto the details:

I've used Lua primarily in two places:

1) A board level manufacturing diagnostic for the 3dfx VooDoo Banshee

   It allowed me to separate the 'unsafe' C code from the 'safe' lua
   code. Since it was a board level manufacturing diagnostic, it had to
   run in DOS (with a protected mode extender), and debugging in that
   environment was not fun, so the less code with segfaul type errors 
   the better. Once I got the core routines exported to Lua, I could
   iteratively get the proper tests working and sequenced the way
   we needed them. Also, all the text-UI for the operator was in Lua,
   more code I didn't have to deal with C-level stuff in.

   It also allowed me to do on-site customization while working with
   manufacturers. 

   This project worked well, and tested every Voodoo Banshee and
   probably all of the VooDoo3 based boards which shipped.

   The biggest drawback of using Lua was that I don't think the people
   who took it over from me appreciated having to learn the script
   language complexity. They probably would have rather had some straight
   C-code. I can't know for sure.

2) A free/unfinished game engine (HZ). 

   This project actually came first and is where I gained positive 
   experience using Lua. However, the game is just a pet-project which 
   does not get enough attention from me. Compared to other languages 
   available (then and now) Lua is much simpler and faster as an 
   embedded extension language.

   Right now I'm actually removing Lua from this project, since I've again
   run into trouble where people just don't understand the project to
   help contribute, and having it half C++, half Lua dosn't help. I also
   think I integrated Lua too early in the project, since I've confused
   myself about where I want the C++/Lua boundary. (Lua isn't really what
   I want to code the _entire_ game in -- because of speed and code
   maintainability, but that's where it's gone right now)

   I do think this was an interesting project to learn from.
   The troubles with Lua in this project have been: (a) It's weak typed,
   and debugging is somewhat difficult in the context of a game where 
   I've not built an interactive Lua debugger. (b) It's hard for others to
   understand the Lua code, both because it's weak typed, and because 
   (like all class-ish lua) I had to build my own inheritence mechanism and 
   the weird syntax makes the code more confusing. 

> Do people around you know Lua? 

A friend of mine experimented it with at his work in digital effects
production. They primarily use Python for scripting tools, and C/C++
for writing custom code which integrates into something else or
renders something. He made a plug-in shader module of some kind using
Lua. He wrote it because using this plug-in allowed him to iteratively
work on the shader without quitting and restarting the environment to
load a new compiled shared object. He thought it was very easy to
learn the Lua API and integrate it into what he was doing, but he
wasn't that pleased with the language and he hasn't used that plug-in
or Lua since.

I have at least two or three other friends who have learned it at some
point. The only one of which who did anything with it was Paul Bleisch
who at least used to be on lua-l.

> How did they know about it? Did you tell them yourself or was it the
> other way around?

In the case of my friend in digital production, I told him about it.

> Do you know other people that are using Lua but who are not in
> lua-l?

Nope.

> Would you rate Lua as a "popular" language? Do you see its
> popularity increasing?

I definetly see it's popularity increasing compared to when I first
stumbled upon it around 1997. Back then nobody knew what it was. Now
several of my friends know what it is, and occasionally someone I run
into knows what it is.

The scripting language I use the most is Python, and it's popularity
is clearly increasing alot more than Lua's. 

If writing mostly in script, I would always start in Python over Lua
because I love the clean syntax, and if something was a performance
problem I'd write C modules later. If integrating a scripting language
to do very small things in a larger C/C++ program I'd probably
continue to use Lua purely for the ease of the API. (interestingly,
I've never tried to use Python in this context)

Although for most of my projects I'm really starting to want a
static-typed scripting environment. Unfortunatly, there dosn't seem to
be one readily available. Java comes close but isn't easy to
integrate, Pike dosn't have enough static type checking (yet?) despite
all it's static declarations. Something like UnrealScript would be
pretty great, too bad that's not freely available.

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net