On Dec 28, 2007 7:47 AM, Jeff Wise <jwise@sealyrealty.com> 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 VB.net 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
direction.
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*
