lua-users home
lua-l archive

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


I dare re-enter this realm, since the challenge it places on the list is - how to deal with commercial establishments, and "rules". If we fail to please Kelly's needs, maybe there's something to be looked into the mirror, too. I think such a discussion never took place earlier on the list.

There's two things. There's Lua core, which hardly needs caring for and asking for roadmaps on it is -well- valid, but not maybe hitting the end of the nail. Lua core will change if (and only if) there's some benefit in the change.

Then there's the Lua 2nd tier, modules. These are in more or less constant flux, and there sure is generous overlap, and generous amount of bugs / bad designs in them. Comparisons of keeping up with Lua and Python become essentially the same if the 2nd tier is also included in the concept.

So, this being the looking in the mirror - what are we going to do about it?


Stephen Kellett kirjoitti 29.12.2007 kello 0:51:

Great answer.

Eric Tetz wrote:
On Dec 28, 2007 7:47 AM, Jeff Wise <> wrote:
In most of my career, no one cared how I implemented a solution, and there was really only one choice, so I avoided this situation. Now that I am forced to do VBA (a Visual Basic derivative for MS Office) and am aware of
the VB6 versus disaster, I see this problem in a new light.
I think your message illustrates how unproductive it can be to argue
generalities. :)
There *are* domains where your tools may be expected to change
rapidly. For instance, if you're using middleware that targets an
evolving platform, you need to know that the middleware is going to
keep up.
For a concrete example, look at Flash. Flash runs in browsers, which
are constantly evolving, so Flash *will* need updating. Flash is a
commercial product, so you cannot update it yourself. Therefore, if
you base a business solution on Flash, you want some assurance that
Flash will be maintained for the life of your product.
Lua "targets" an ANSI C machine. C has been around for 35 years with
minimal changes, and shows no sign of stopping. You will probably be
able to compile today's Lua without change 20 years from now; there is
no built-in expectation that Lua will *need* to be changed. If such a
need did arise, you have the full source; there is no built-in
dependence on a third party.
So it doesn't make sense to talk about Lua in the same way you talk
about Flash or some other rapidly changing implementation technology.
It's a useful tool today, and while updates may come in the future to
make it even better, you will never *need* them. Choosing to use Lua
in your product today does *not* make you dependent on Lua's future
If you can't justify the use of Lua in a particular problem domain,
then perhaps it really is the wrong tool for the job. *shrug*