 |
lua-l archive |
|
|
||
|
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_.