Re: new releases [was Re: Official public code repository]

[David Manura <dm.lua@...>]

Tim Kelly writes:
> ...but it is still difficult to compete with a solution based
> on Microsoft's C# (as mentioned in another email).
> MS isn't going away any time soon.

But Lua is not a direct competitor to Java/C#/C++/C/Perl/Python/etc.  For one
thing, Lua's class libraries are no match to those of Java/.NET and even Perl. 
Further, not every problem is a nail, and Lua can be the right tool for the job.
 You can use Lua with these other languages if you like, even manipulating
Java/.NET objects from Lua or vice-versa--but maybe a scripting language native
to that VM would be more appropriate.  You can treat Lua as just another library
in one of these other languages, similar to how one embeds the language of
regular expressions via a regular expression library.  There's not much
complaint that a regular expression library is not constantly changing if it is
feature complete, stable, and has a large user-base.

> The Lua interpreter might compile but be broken.

Unlikely under a supposedly ANSI C compiler.  However, there is a test suite:
http://lua-users.org/lists/lua-l/2006-03/msg00716.html .  One could also run
test suites of modules.

> Are there alternative Lua interpreters?

See "Alternative implementations of Lua" in http://lua-users.org/wiki/LuaAddons
.  Many of these are not nearly as stable/complete as the C version of Lua,
probably due to lack of need (except maybe LuaJIT, if that counts, and I haven't
tried the .NET version).

> In business, "change is good, it's hip, it's happening, the company
> is forward-looking and on top of new technologies." 

The place where things are happenin' is not the Lua core.  It's the libraries:
LuaForge, LuaRocks, Kepler, Metalua, Lua.NET, ExtensionProposal, etc., as well
as LuaJIT.  These are things to be more concerned about if you may need them.

> That is what appeals to business managers - if a company has
> to constantly "evolve" their product to continue a revenue stream,
> that in itself is motivation for continued development, and
> therefore continued support.  Five years is not a long time for
> a project lifetime.  "Middle aged" is how I would refer to it.

Say, in the hypothetical extreme case, that the core developers do nothing over
the next five years: no bug fixes and especially no feature changes.  Interested
users most likely discover a dozen more mostly minor bugs and post a patch
somewhere (e.g. on the wiki).  Maybe some newer compilers introduce a few easily
resolved quirks as well (e.g. like _CRT_SECURE_NO_DEPRECATE under MSVC)--that's
the job of LuaBinaries.  I see little reason for your code (and mine) not to
still run fine after 5-10 years with few complaints because there's so few
dependencies.

However, libraries are a different matter.  Maybe you use some Lua libraries to
interface to some OS component and that interface changes (maybe to harden OS
security).  Your Lua library will need to be upgraded, and you may need to do
the rewriting.  The "Alternative implementations of Lua" will also mature if the
need exists.

> What I am looking for is a "roadmap" that says official releases
> will be available, these are the people in place to ensure the
> servers are up and running, here is a list of bugs to be addressed,
> here is why stability is not "end-of-lifed."

I'm not sure what "end-of-life" means in the context of the Lua core.  I believe
Lua 1.0 is still usable.  Anecdotally, in LuaCOM, we're likely dropping Lua 4.0
compatibility (and maybe Lua 5.0 as well) in the main line due to cost of
maintenance and lack of interest in 4.0+COM, though Lua 4.0 users could continue
to use the older version of LuaCOM if they like.