Zoom out

[John Belmonte <jvb@...>]

Even though I'm in Lua's "embedded camp", and am already satisfied
with Python for system programming tasks, I can certainly understand
the view of people like Philippe.  Indeed, if a system programming
environment with Lua's simple style and Python or Perl's reach
existed, I would be eager to use it also.

However, Lua has the ANSI C constraint.  More limiting, the authors
are careful that the language be useful even if a file system is not
available.  These two constraints make Lua wonderful for embedded
programming.  Being limited to ANSI C has another advantage, as it
forms a well-defined boundary on the Lua distribution's realm.  I
think it keeps the Lua authors focused on the language, not on making
system programming libraries such as those included with other
scripting languages.  This in turn avoids having to impose an
implementation of classes and other higher-level constructs which would
be required to support big libraries.

What we have are the ingredients to make something new-- an efficient
scripting core with a simple style and well-defined C interface, and a
growing group of people who would like to see a system programming
environment based on that core.  You can image that inside Perl and
Python are cores similar to Lua-- not well defined because they never
existed independent of their high-level scripting language-- but cores
nonetheless.  (The fact that the functionality of Lua is equivalent to
the core of these heavier languages, together with the focus given by
the Lua authors, is the reason it runs so much faster.)  So here is an
opportunity to make a high-level system scripting language from the
bottom up, instead of top-down.  Not only that, but you have an
experienced team working on the core.

So what I'm suggesting is that someone, or some group, take charge of
this new thing.  Give it a mailing list and development site.  But
most importantly, take a new perspective-- don't call it Lua, even if
by license you can.