Re: ActiveState seeking Lua community feedback

[Frank Kastenholz <fkastenholz@...>]

Hi

A couple of thoughts on this topic

The base Lua distribution from PUC-Rio has a number of extremely valuable
properties as it comes from PUC-Rio.  If, in the process of adding commercial
support (which is A Very Good Thing), you end up reducing or eliminating those
benefits, it would be A Very Very Bad Thing.  

For the project that I recently finished, our end customer was very unsure about
us using Lua ... they were so unsure about it that it went to very high management
levels and I ended up making a whole lot of "why Lua is Good" slides (can't share
them, sorry).  Anyway, some of the good things (that should not be lost) are

- PUC-Rio Lua is extremely stable and seems extremely bug free. The low number of
  releases, along with the low number of follow-on bug-fix releases and the low number
  of bugs they fix in each (which fixes all known bugs) attest to this. In my customer's
  environment, the software-update-rate is measured in years, so never-ending streams of
  bug fixes would be Bad.  

- The VM in PUC-Rio Lua is pretty safe (or can easily be made so by removing a few 
  Lua-callable functions like "os.execute").  

- PUC-Rio Lua is small.  Code space for Lua is O(300KB) ...and today, "Kilobytes" often
  are considered rounding errors. Any added libraries, functions, etc, should keep this
  in mind and not bloat it.  The environment where the software I develop runs measures
  memory in 10's of MB, and my customer is considering migrating things to smaller
  devices which might be <5MB, possibly less than 1MB.

  I realize that adding things adds to memory requirements ... but if you could make your
  extensions optional at build time, that would be really cool.

- All The World Is Not Linux, nor is it even Posix (nor Windows nor OSX...).  
  Again, PUC-Rio's Lua has very few, if any, requirements on the underlying OS. 
  C99 is a reasonable level of requirement on the underlying system. C++ would
  be really bad -- both from a portability perspective and a memory requirement
  perspective.

  One important thing here is that including object-code extensions as "libxxx.so"
  is not always useful. It presumes that the underlying OS has a dynamic linking 
  ability. It may not.  At the very least, there should be an option to build the 
  extensions directly into the executables (or be able to package the individual
  object files with the base Lua).

  Another thought --- the underlying "OS" might not even have a useful file system
  in which you can store extension_module.lua ... so how about a build option to
  take extension_module.lua, wrap it in C as a big string, and hard-compiling it in?

- The current license for Lua and most, if not all, extensions, is perfect.  GNU licenses,
  for my environment and customer, are extremely limiting, if not completely
  unsuitable.  This includes the LGPL.

I realize this isn't a "add feature XYZ" list, but to be honest, Lua is pretty good as it
is.  

Frank Kastenholz