tech-userlevel archive

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

Some requirements for a scripting language (Was: Lua as a scripting language in NetBSD)

Hi guys,

(Skip to "to sum up" if you want the very short version of the following

On Sat, Oct 17, 2009 at 11:39:35AM +0200, Marc Balmer wrote:
> I am suggesting to add the language Lua to the NetBSD base system as a  

I won't add any fuel on that discussion, but I'd like to add a few
points that I haven't really seen mentioned in the rest of the thread.

FWIW, Core had been contemplating the idea of a "modern" scripting
language for inclusion in base.  It's not my place to give any details
of what was discussed, but I did play around with Lua and later Python.

My opinion is that the very first requisite for such a piece of software
to be included in base is that it has to be easy to integrate.  This is
the case with Lua;  integrating it into the build was a matter of a few
hours of work, and that includes a couple extensions such as lcurses and
a regex module.

Then I went on and tried with Python.  I didn't try for very long;  not
only the build system is close to a nightmare, but it now has some MD
components that I am not sure we have yet support for on all archs.  Not
that it would be a lot of work, but it adds to the complexity and thus
make it even harder to maintain.

This is very important:  doing the reachover build once is one thing,
but what matters is when you have to update.  In that respect, Lua is a
clear winner.

There is, however, a second thing that I see as an absolute requisite
for inclusion in base.  For many kinds of software, interaction between
base and pkgsrc is not a problem.  But when a piece has a notion of
modules, it becomes a hairy problem.  It is actually two folds:  the
first issue is how to install additional modules from pkgsrc.  I think
Marc argued that one that that could be done is completely shielding the
base language (Lua in his case, but really it applies to anything) from
the rest of the world, including pkgsrc).

This appears to me as a very short sighted opinion, especially coming
from someone who claims a scripting language should be included in base
for the sole reason of generic usefulness.  Well, if something can be
used for "stuff", someone will want to use it for "stuff and more".
Therefore people will want to install additional modules from pkgsrc.

The thing is, pkgsrc is very independent from its base system, NetBSD
for the sake of that discussion, which means paths can't be hard-coded,
not in base nor in pkgsrc to help the scripting language find its

That leaves the options of either pkgsrc installing files outside of
LOCALBASE, or devising a way to patch the base scripting language to be
configured an extra search path.

The second issue regarding interaction with pkgsrc is what is supposed
to happen when the base system is upgraded.  That can lead to very
harmful ABI issues, especially if the scripting language gets wide use,
and solving them is far from easy.  One can always start properly
versioning modules, so that scripts could fail similarly to ELF binaries
that can't find their libraries.  But it also means that one kryteryon
to choose a scripting language would be to have a module API (and ABI,
for many languages, including Lua, can see their modules compiled one
way or another) as stable as possible.

Finally, and this is in my opinion the only real thing worth debating,
there is the question of whether inclusion of a scripting language
should precede its use in base, or whether it should be the other way
around.  I tend to be of the opinion that many things could be done with
a scripting language, so that if it exists, it will find its place.  But
I know that many people feel that it shouldn't be included before
someone has something else worth inclusion that uses it.  I think this
discussion can serve as a midway, giving a short list of languages to
consider for anyone to, say, write a script-based sysinst or something.

So, to sum up, my opinion is that the three following things are
requisites to consider inclusion of any scripting language:
  1 easy integration, to make future maintainance possible
  2 full interaction with pkgsrc
  3 immediate use case.  how immediate is up for debate, though.

Now, there can be a lot of arguing over the features of the scripting
language.  For the language itself, I honestly think it is completely
irrelevant.  The amount of available extensions, however, is more
relevant.  In that respect, Lua does not do as good as Python, for

In the end, there is something I think NetBSD could do, especially
given how straightforward it is to integrate Lua into the tree.  Why not
simply give it a try for NetBSD 6.0, and see what people do with it?  I
don't see how -current could instantly be irremediably dependent on Lua,
which means removing later won't really hurt anyone if doesn't see any
relevant use.  If it *does* get immediately dependent on Lua, then it
will be a sign that it wasn't a bad idea after all.

And if it is somewhere in the middle, seeing use but not being critical,
then it can be discussed for the next major version.  But I don't think
that NetBSD has to take an oath about supporting a scripting language
from the very start to the end of time.

(If you're insterested, you may find my patches for Lua here:
They might still compile with current -current, or might not.  I really
have no idea.)

Quentin Garnier - -
"See the look on my face from staying too long in one place
[...] every time the morning breaks I know I'm closer to falling"
KT Tunstall, Saving My Face, Drastic Fantastic, 2007.

Attachment: pgpXz70dCWtGz.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index