lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

I understand your writing, but the concerns presented don't really seem very valid, to be honest.

Maybe this is based on Perl versions taking so long (maybe forever for Perl 6), but the simplicity and lightweight of Lua, and its separation of language from the extension modules clearly makes the concern way, way lesser. To be just, Lua already relies on many authors, unless you don't use any extension modules at all. As long as everything is MIT/X11/Lua5 licensed, there shouldn't be a worrying cloud on the sky. Maybe your managers / decision makers need to realize the mere difference of size between Lua (200kB) and Perl, Python, Ruby, C# and others (10MB or so).

Also, Lua's metamethod way of thinking is one factor contributing to this resistance for change. In order to do things differently with Lua, you don't often need to change the language. With metaLua / luaSuper, this will also cover any syntax issues.

Finally, while public exposure to Lua has been scarce, there is a wide base of highly knowledgeable consultants available to be utilized in any potential difficulties. This is not specific to Lua, but to any successful open source project. You cannot patch the internals of C# even if you wish (*). With Lua, you can if really necessary.

- asko

(*) I recently finished a C# 2.0 project. In C#, == and != operators work by reference for _any_ objects except for strings. So, comparing two identical IP addresses via == will normally give false, even if the values are the same! if (a.Equals(b)) is the right way to do. if (a==b) is silently erroneous. Who the .... would want such behaviour? One can override '.Equals', but not change the '==' to value semantics. Having a big company "back up" a language does not make it perfect.

Tim Kelly kirjoitti 26.12.2007 kello 20:17:

Roberto wrote:

More seriously, I am afraid I missed something. what do you mean by
"official support"? If you mean bug corrections and code maintenance,
one of the main ideas behind Lua is that you do not need us to give
you this assurance. Lua is simple enough to be maintained in- house, if
necessary (even for small "houses").

By "official support" I mean PUC-Rio's team, or an alternative group that has assumed responsibility. When trying to pitch a solution based on Lua, or any technology, management decision- makers raise the question regarding the long-term viability, especially against PHP or Perl. It's perverse mentality, to be honest. You state you are happy with Lua and suggest little changes will occur in the future (which is a good thing); management sees this lack of constant updates as a possibility the project will go away, or worse, Lua developers will join forces with COBOL programmers and keep the virtual keys to the server room (COBOL hasn't changed in years, either ;-).

(That said, we do plan to keep playing with Lua for several years.)

So instead of a roadmap for versions, how about a roapmap for future keepers of the flame? The discussion thread started out as a question about an official code repository. I believe this to be a legitimate concern, and should be under the auspices of the central development team that can apply bug patches, even if Lua can be maintained in-house, as you state. There can be lots of unofficial patched versions of Lua, but there should be an official version that developers pitching solutions can point to in order to give assurances to those writing the checks that the developer can be replaced and the technology (Lua) is independent of that developer. The developer can't be the one pitching the developer's patched version of Lua. Too much dependence on that developer.

Alternatively, if I have missed something and this is already laid out clearly, please direct me to it :-)


"Anything war can do, peace can do better."  --  Desmond Tutu