Re: Lua Strengths/Weaknesses and usage info

[Christian Vogler <cvogler@...>]

On Tue, May 15, 2001 at 11:44:09PM -0700, David Jeske wrote:
>  - 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 disagree with that part. IMHO the tolua framework for classes is
quite nice, and easy to use and to understand. You can use it even
when you do not define C++ classes. Its biggest drawbacks are that
when you bind C++ classes you have to mess with ownership issues, and
that there is currently no way to override virtual functions from
lua. 

However, the first issue was easy to fix with some tag method magic.
Likewise, the second issue should be, from what I know about how tolua
works, fairly easy to implement in the tolua code generation module.

I am inclined to agree, though, that the weak typing can be a
problem. It makes it hard to track down errors when you pass the wrong
class to a function.

I like the metamechanisms in lua very much. They make the language
very powerful, and you can do some surprising and useful things with
them that make the overall project easier to use.

My biggest gripe with lua is the lack of libraries that make
general-purpose scripting hard and verbose.

We use lua in a framework for tracking deformable models with computer
vision methods. It functions both as a language for configuration
files and as a general-purpose scripting language. As a configuration
file language, it has by far exceeded our expectations. For example,
we have to describe the topology and shape of 3D polygonal models. lua
allows us to compute the shape mathematically on the fly, which makes
it so much easier to write these files.

As a general purpose scripting language, we primarily use it to
control the visualization frontends, and setup and flow of the
tracker. Even there it has shown to be amazingly powerful in that tag
methods allow us to observe when the contents of a table change,
wihout the function making the change having to be aware of the
observation. This makes for a very clean decoupling of the GUI and
program flow logic, and allows us to reuse components for different
frontends without any fuss at all.

On the other hand, this is also an area where we have had to come up
with some ugly hacks to compensate for the lack of library
functions. For example, we have a directory full of images that are
named like this:

image.0001.pgm
image.0002.pgm
...
image.0500.pgm

>From this directory we need to find out how many images are there and
what the first and last frames are. From lua, this turned out to be
surprisingly hard to do. We eventually settled on a combination of
system("ls") and the string pattern functions, but the result is
neither robust (we end up with broken pipes frequently), nor easy to
understand.

>    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.

We've partially gotten around the problem by giving access to an
interactive lua interpreter from the main program. This lets us
inspect and modify code and variables at run time.

> (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. 

How does weak typing make code harder to understand? Or do you mean
the difference between static and dynamic typing? If it is the latter,
I would argue that it is a matter of taste. Both static and dynamic
typing have their advantages and drawback. One nice thing about
dynamic typing is that writing generic code comes naturally, without
having to resort to e.g. C++'s nasty template syntax. In such cases I
would argue that the code is actually easier to understand than the
statically typed version.

- Christian