RE: Lua documentation, Python, etc.

[Terry Moore <tmm@...>]

At 11:29 AM 6/5/2002 +0100, you wrote:
> > I don't want a flame fest on the issue, but would appreciate comments 
> > on pros and cons of the two different languages for those that have 
> > used both, because once I make this decision, I'm kinda committed =|
>
>
>John has pointed out a few of the obvious points.

And so has Nick.

Here's our experience, taken from a commercial perspective.  MCCI uses Lua extensively, both in tools and for cross-platform script development (Win32 and NetBSD).  Because we use it in tools, we didn't adopt Python; one less language to support, and Python was not what we needed in the tools.]

[Our primary embedded-tool use is a version of bsdmake which we've modified to run on Win32 as well as Unix, and to handle cross-compilation issues better.]

Using Lua extensively in scripts required a couple of local changes to the lua.c engine and the compiler.  They were trivial -- but the coder involved was an experienced language implementer, so YMMV.

[I'll post a detailed list of the changes we found necessary in a separate thread, in case anyone is interested.]

We've been very happy with Lua for these purposes.  One very nice feature of LUA is that we can ship scripts in binary to our customers.  Why?  Not to hide things from the customers, but rather so that we know that a given configuration matches what we shipped.

Of course, with Lua 4 (and 5 soon) we have to deal with backwards compatibility issues.  I could wish that this were better addressed at the command level:  it would be much easier to support back versions if the lua command had the version number embedded, or if the lua command had the logic in it to launch a back version if the current script doesn't work.

In other words, using LUA in production with a large number of scripts and an installed can be a problem if you want to share your work with others, or take advantage of work done by others.  We wanted to use the XML tools that have been posted; this forced us to upgrade to Lua 4; this forces us to deal with a number of compatibility issues, including our deployed base.  

Not that I'm complaining -- we've seen this with commercial tools, too.  It's just something one has to budget for, if one wants to take maximum advantage of working with the Lua community.  

[This could be taken as a suggestion for future research directions!]

--Terry