Justify introducing Lua at my workplace? (on topic)
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Justify introducing Lua at my workplace? (on topic)
- From: Duck <duck@...>
- Date: 2007年11月29日 12:06:44 +1100 (EST)
I have an opportunity to introduce Lua in my workplace.
My goal is to replace an existing scripting language.
The existing language is proprietary, was developed
in-house, has limited functionality, is hard to maintain
and extend, and is only maintained by its inventor.
[But as the boss] says, the existing language is working
(for now) and we have several developers who are trained
to use it. These developers would have to learn Lua.
Since Lua is so small and easy to embed, you could even start by simply
treating Lua as _an extension language for your scripting language_.
This is not as weird as it sounds -- it makes the change organic, not
revolutionary. It allows developers time to acquire knowledge of the new
language. It doesn't throw out the baby with the bathwater.
Many in-house scripting languages start as extensions to solve a very
specific problem, which they do with astonishing efficiency. Only when
they start getting stretched to become a general-purpose extension do they
become troublesome.
If this is what has happened, _adding_ Lua into the mix will give a path
along which you can pare back use of the in-house language to those cases
for which it was originally created.
You might end up with the original in-house language emedded in Lua. You
might eventually be able to dispose of it altogether. But by avoiding
switching over up front, you take care of:
1. The ego of the inventor. (He or she might have a touch of, errr,
cognitive dissonance about letting the new language in :-)
2. The fears expressed by the boss.
3. Concerns from the developers about a "jump discontinuity" in
productivity.
4. Risk to the product whilst testing and validating the changeover.
Incidentally, it was a desire to do something very much like this which
brought me in touch with Lua in the first place -- I wanted a string
library, of at least AWK-like functionality (internal memory management,
familiar programming style, easy to learn, small), not under the GPL, to
add into a C program to replace messy internal file parsing code.
What happened was that I found Lua, a full-blown programming language,
smaller than most of the string libraries out there, which just happened
also to include a better string library than most of the string libraries
out there :-)
So, instead of switching to Lua, you might even consider just introducing
it as, say, the "addon library" for your current language through which
you provide support for, say, associative arrays (tables)...it would be
worth it, and small enough, _for that alone_.