lua-users home
lua-l archive

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

On Dec 27, 2007 8:40 AM, Tim Kelly <> wrote:
"In business, 'change is good, it's hip, it's happening, the company
is forward-looking and on top of new technologies.'  [..] I still have
to overcome it when bidding on projects.  I don't have to overcome it
if I pitch PHP or Perl or MS.  They don't stand still."

You want your *product* to change, you want your *product* to keep
with it's competitors, you want your *product* to support the latest
technologies, if that's what it's supposed to do. You *don't* want
your product's IMPLEMENTATION to be based on emerging and/or rapidly
changing technologies, if it can be helped. You do your best to build
a house on a solid foundation, you don't actively seek out quicksand
to build on.

"I have had to answer a client's question 'What happens if you get hit
by a bus tomorrow and die?' as part of the bid process."

That question is much easier to answer for a stable technology. What
happens if Lua stops changing? Nothing. It's done. It hasn't changed
recently because it hasn't *needed* to change. That's a *good* thing.
That should give you confidence. You're not dependent on a moving

"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.'"

Why? You have the source code! You copy it into your product's source
tree, and it's now part of your product. It CANNOT be "end-of-lifed"
-- that notion has no meaning in this context -- it requires no
third-party support, it requires no servers to be up and running, the
entire Lua team could move to the Moon (^_^) and it would have no
impact on your product whatsoever.

Part of Lua's virtue is that is has a very small, modularized,
easy-to-hack implementation; easy to embed, easy to extend, and
written in very straight-forward, portable ANSI C. It's not that you
*have* to support it yourself, it's that you *can* support it
yourself. That has value.

"Stability can and does include evolution.  Failure to evolve leads to
extinction.  Extinction is not stability."

How is that's relevant to a programming language? People are still
using Lua 4, or earlier versions. How does that hurt them?

The version of C in common use today (C89) is nearly 20 years old, and
shows no sign of pending 'extinction'. Change is often *bad* for a
programming language, and must be considered *very* carefully, which
is exactly what Lua's authors have always done. Characterizing a slow
rate of change as *bad* is completely backwards.

"if a bidder were to say they products do not need ongoing
maintenance, they will be eliminated from consideration as being a

Again, your *product* may need ongoing maintenance, but that should
NOT be because your implementation is dependent on technologies that
are changing under you feet.

"Everyone here knows that Windows and Linux (and even BSDs) need
patching regularly and so do the scripting languages, as they are all
full of security holes."

When's the last time Lua was patched to fix a "security hole"? Windows
and Linux are OPERATING SYSTEMS, of orders of magnitude greater
complexity than Lua (and Perl's probably not far behind ^_^). Perhaps
the scripting languages you're referring to need constant patching
because they are constantly changing?

"I do think it bizarre that people writing Lua scripts are expected to
be able to maintain their own version of Lua."

Lua is designed to extend applications *and* to be extended by them,
so that it almost becomes an application-specific language.

"Instead, I feel rather attacked for asking for assurances of long
term stability."

You seem to have defined stability as "assurance of change", which is
the *opposite* of stability. If you want a stable scripting language,
grab the Lua source and don't change it. If you want assurance that
there are no unknown issues, grab an older version.