[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Lua in astronomical image processing
- From: Nicolas Devillard <ndevilla@...>
- Date: Thu, 17 May 2001 10:30:24 +0200 (MET DST)
The project I am working on is an image processing library for
astronomers. The main development is a C library providing low-level
functionalities. We have a need for a high-level language to script this
library into useful astronomical applications.
Python is cool, but there are several things getting in the way:
- Python is BIG. Something like 10 times the size of our own code.
In the end I do not know if I am adding Python as a scripting
language to my library, or making my library a Python extension!
- The C bindings are too hard to write by hand, especially for many
functions. SWIG is great but does not handle type conversions too
well, some handwork is still needed there. Not a showstopper but
an additional task nonetheless.
- Our package must be used by non computer experts. I do not want to
become a Python installation helpdesk.
So Lua fits the bill quite well: small, as easy to program (probably less
powerful than Python but for our purpose it's just right), small to
download, easy to install, easy to interface to C, we can distribute it
with our code without exploding the tarball size. Great. Only thing is:
coming up to users with yet another language to learn is a non-trivial
persuasion task. Even if you can convince them that the language is
simple, they do not want to hear about it.
So right now we are in the phase of offering both Python and Lua to
interested programmers. We will see which one wins, where the interest
goes. If nobody wants to use Lua, we will keep it for internal use only.
Internally, we use Lua a lot to help us generate C code, e.g.
you can store a data structure as a tree of Lua tables and have them
generate themselves into a static struct which you can #include in your
library. Very handy, much easier to maintain, and you can completely
re-organize your data structure without messing the handling C code.
Cheers
--
Nicolas