Why Lua is not more popular

classic Classic list List threaded Threaded
59 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Why Lua is not more popular

Pierre Chapuis
I think this graph resumes the problem well.

Apparently, when picking a language, people
consider the availability of Open Source
libraries the most important criterion and
simplicity the *least* important...

http://alarmingdevelopment.org/?p=826

--
Pierre Chapuis


Reply | Threaded
Open this post in threaded view
|

Re: Why Lua is not more popular

Tim Hill

On Sep 13, 2013, at 1:00 AM, Pierre Chapuis <[hidden email]> wrote:

> I think this graph resumes the problem well.
>
> Apparently, when picking a language, people
> consider the availability of Open Source
> libraries the most important criterion and
> simplicity the *least* important...
>
> http://alarmingdevelopment.org/?p=826
>
> --
> Pierre Chapuis

Well, I'm really not sure how you measure "popular". Lua is an embedded language and thus often is not "visible" even when critical to a project. For example, Lua is used in the UI of all Amazon Kindles .. does anyone know that? Do they factor this in when they measure "popular"? And what about all the games that use it?

--Tim



Reply | Threaded
Open this post in threaded view
|

Re: Why Lua is not more popular

steve donovan
In reply to this post by Pierre Chapuis
On Fri, Sep 13, 2013 at 10:00 AM, Pierre Chapuis <[hidden email]> wrote:
> Apparently, when picking a language, people
> consider the availability of Open Source
> libraries the most important criterion and
> simplicity the *least* important...

So, in short, people like using stuff that's familiar to everyone on
the team, with lots of nice free libraries without legal restrictions.

'simplicity' is a problem word: I suspect people think it means 'simplistic'.

And as Tim says, real languages get used and don't make a fanfare
about it.  Despite being deeply unfashionable, C is still everywhere,
and Lua is everywhere in games.

Reply | Threaded
Open this post in threaded view
|

Re: Why Lua is not more popular

Pierre Chapuis
In reply to this post by Tim Hill
> Well, I'm really not sure how you measure "popular". Lua is an embedded
> language and thus often is not "visible" even when critical to a project.
> For example, Lua is used in the UI of all Amazon Kindles .. does anyone
> know that? Do they factor this in when they measure "popular"? And what
> about all the games that use it?

Yes, I know [1]. I should have probably said trendy instead.

Lua is one of those languages so many things run on but
most people don't know about (except in games and embedded
software).

Anyway that was definitely not an attack on Lua. I for one
care about simplicity. I guess what this graph says is
that if we want Lua to become *even more* successful we'd
better improve the availability of Open Source libraries.

Which is what we're doing, right? After all, we have passed
the 300 rocks milestone recently :)

[1] http://files.catwell.info/presentations/2013-02-human-talks-lua/

--
Pierre Chapuis


Reply | Threaded
Open this post in threaded view
|

Re: Why Lua is not more popular

steve donovan
On Fri, Sep 13, 2013 at 10:36 AM, Pierre Chapuis <[hidden email]> wrote:
> care about simplicity. I guess what this graph says is
> that if we want Lua to become *even more* successful we'd
> better improve the availability of Open Source libraries.

Oh yes, if I didn't care about simplicity (and performance) I would
use Python like everyone else ;)

But people want what they want, except better.  Where I work, numpy is
the big reason I can't recommend Lua (which is fine; I'm not an
evangelist)   GSL-shell is awesome (very fast) but there is only one
Francesco, whereas the big Python numeric stack has actually had
serious real money put into it. One would need in effect a second
Kepler project to do numerics properly.

Reply | Threaded
Open this post in threaded view
|

Re: Why Lua is not more popular

Steve Litt
In reply to this post by Pierre Chapuis
On Fri, 13 Sep 2013 10:00:15 +0200
"Pierre Chapuis" <[hidden email]> wrote:

> I think this graph resumes the problem well.
>
> Apparently, when picking a language, people
> consider the availability of Open Source
> libraries the most important criterion and
> simplicity the *least* important...
>
> http://alarmingdevelopment.org/?p=826

Yes. I've mentioned open source libs as a reason I still use Python.

Most of the time, I'm in a position where I have to get it done in a
day or two. With Python, I can be pretty sure I can find the libs I
need to get the job done, whether it's SNMP, directory stuff, regex, or
most other things. Those libs will be tested and will be part of the
Python distribution. In other words, I can be pretty confident, when
using Python, once I've designed the thing, I can code it in a couple
days by just using libraries.

With Lua, there are many competing libraries in various states of
completeness and stability, so there's *much* more research required,
and I might end up needing to code from scratch a problem domain I
hardly understand. So the time I would have saved by using tables for
absolutely everything, and having functions just another piece of data,
and having closures, is often lost when I need to research or re-wheel
libraries.

By the way, I do office automation type programming, not embedded or
games. Obviously if I did game programming I wouldn't care about libs
for SNMP or database access and the like.

Like I mentioned before on this list, if we had some sort of wiki where
people could put their experiences with various things they grab out of
LuaRocks, as well as how they solved various problems, it would open up
Lua to a whole different group of people, because as a language, Lua
blows the doors off of Perl, Python, Ruby, C++, C, Java, etc. There's
something so incredibly beautiful about all complex data being
constructed from tables.

Thanks,

SteveT

Steve Litt                *  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance

Reply | Threaded
Open this post in threaded view
|

Re: Why Lua is not more popular

Jayanth Acharya
As someone (myself that is), very new to Lua -- which I got introduced to, thanks to a small section in FreeSWITCH documentation, I'd say that the "batteries not included" did seem a bit "unusual" and slightly "challenging". However, now about a week into my learning, and my first realistic yet tiny application nearing completion, I've found libs that work as advertised (e.g. "luars232", "alt-getopt" and "luasockets"). Also, I've installed all the luarocks that I found interesting at the luarocks site, but yes, there are a few which I am confused about (e.g. "watchman" vs an alternative that was suggested). Had one of those two been on luarocks site, I might have had less doubt.

OTOH, the relatively tiny size of Lua download, was such a welcome change !


On Fri, Sep 13, 2013 at 3:21 PM, Steve Litt <[hidden email]> wrote:
On Fri, 13 Sep 2013 10:00:15 +0200
"Pierre Chapuis" <[hidden email]> wrote:

> I think this graph resumes the problem well.
>
> Apparently, when picking a language, people
> consider the availability of Open Source
> libraries the most important criterion and
> simplicity the *least* important...
>
> http://alarmingdevelopment.org/?p=826

Yes. I've mentioned open source libs as a reason I still use Python.

Most of the time, I'm in a position where I have to get it done in a
day or two. With Python, I can be pretty sure I can find the libs I
need to get the job done, whether it's SNMP, directory stuff, regex, or
most other things. Those libs will be tested and will be part of the
Python distribution. In other words, I can be pretty confident, when
using Python, once I've designed the thing, I can code it in a couple
days by just using libraries.

With Lua, there are many competing libraries in various states of
completeness and stability, so there's *much* more research required,
and I might end up needing to code from scratch a problem domain I
hardly understand. So the time I would have saved by using tables for
absolutely everything, and having functions just another piece of data,
and having closures, is often lost when I need to research or re-wheel
libraries.

By the way, I do office automation type programming, not embedded or
games. Obviously if I did game programming I wouldn't care about libs
for SNMP or database access and the like.

Like I mentioned before on this list, if we had some sort of wiki where
people could put their experiences with various things they grab out of
LuaRocks, as well as how they solved various problems, it would open up
Lua to a whole different group of people, because as a language, Lua
blows the doors off of Perl, Python, Ruby, C++, C, Java, etc. There's
something so incredibly beautiful about all complex data being
constructed from tables.

Thanks,

SteveT

Steve Litt                *  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance


Reply | Threaded
Open this post in threaded view
|

Re: Why Lua is not more popular

Pierre Chapuis
> Had one of those two been on
> luarocks site, I might have had less doubt.

Yes, that certainly helps.

I don't know what talks are already planned at the
Lua Workshop but I think a BoF with people who write
libraries on LuaRocks would be interesting. Those
who follow the dedicated mailing list know we've
started discussing the next rockspec format and maybe
a merge with LuaDist...

Other topics could be how we can increase visibility
and discoverability of libraries (like what Steve Litt
proposed earlier in this thread), how we deal with LuaJIT,
and the role of MoonRocks in that ecosystem.

--
Pierre Chapuis


Reply | Threaded
Open this post in threaded view
|

Re: Why Lua is not more popular

dcharno
In reply to this post by Pierre Chapuis


On Sep 13, 2013, at 4:00 AM, "Pierre Chapuis" <[hidden email]> wrote:

> I think this graph resumes the problem well.
>
> Apparently, when picking a language, people
> consider the availability of Open Source
> libraries the most important criterion and
> simplicity the *least* important...
>
> http://alarmingdevelopment.org/?p=826

I've tried to evangelize Lua on a number of projects. The issue for me has been standard libraries and the realization that there's not much interest in positioning Lua as alternative to other standalone scripting languages. I work on embedded platforms were size and performance are valued. People concede Lua is smaller, cleaner and faster (especially with LuaJIT). But, the platforms are changing and size has become much less an issue. Team members feel if we're going to add another language it might as well be something we can use on both the target and development machines for tools and various utilities. Python is already ubiquitous there and has a decent set of libraries builtin. That makes it hard to get enough "critical mass" for Lua adoption.
Reply | Threaded
Open this post in threaded view
|

Re: Why Lua is not more popular

Dong Feng

2013/9/13 dcharno <[hidden email]>


I've tried to evangelize Lua on a number of projects. The issue for me has been standard libraries and the realization that there's not much interest in positioning Lua as alternative to other standalone scripting languages. I work on embedded platforms were size and performance are valued. People concede Lua is smaller, cleaner and faster (especially with LuaJIT). But, the platforms are changing and size has become much less an issue. Team members feel if we're going to add another language it might as well be something we can use on both the target and development machines for tools and various utilities. Python is already ubiquitous there and has a decent set of libraries builtin. That makes it hard to get enough "critical mass" for Lua adoption.

I find the contrary in some projects. I need to convince nobody to integrate Lua because it just like using boost::shared_ptr in your project. I only need to guarantee my use of Lua is local, and then others start picking it to solve their problem, and slowly some effort is put to coordinate the project-wise use.
Reply | Threaded
Open this post in threaded view
|

Re: Why Lua is not more popular

Andrew Starks
In reply to this post by steve donovan

On Fri, Sep 13, 2013 at 4:14 AM, steve donovan <[hidden email]> wrote:
But people want what they want, except better.  Where I work, numpy is
the big reason I can't recommend Lua (which is fine; I'm not an
evangelist)

---
FWIW, I've been a self-described evangelist and have now calmed down about that.

For our project, Lua is truly the best choice. We're integrating broadcast video APIs and are using Lua to expose behavior that would otherwise need to be written in C. For example: we're writing all of the iterators in Lua so that file position, styling and composite keyframing can be re-made "in the field."

This is the kind of embedding that is typically beyond the imagination of someone that thinks of Ruby or JavaScript in the role of "letting users script our software."

We're on machines that have a hard cost of about 5k (plus the broadcast hardware). They have gobs of memory and processor cores. Yet, Lua's size and installation ease are extremely important. It's a dependency that is very easy to handle in our project and its size makes us trust it. Any time we have had library that causes issues and our answer has been to "try the update," it's proven to be a burden to us. Lua is the perfect example of the opposite of that kind of experience.

But as an application language, I can think of few modern choices that are worse than Lua. It's verbose, there aren't many libraries, etc.

All things in their place. What is so, if I may, *precious* about Lua is that it is so focused. As I would lament the lack of XYZ, I was also enjoying the benefits of a focus that was keeping XYZ away. 

My point is that this is a truly special project. By special, I mean "rare" and I also mean "specialized." Perhaps when Lua becomes more popular, it will also be the day that this is no longer true.

-Andrew
Reply | Threaded
Open this post in threaded view
|

Re: Why Lua is not more popular

Roberto Ierusalimschy
In reply to this post by Pierre Chapuis
> I don't know what talks are already planned at the
> Lua Workshop but I think a BoF with people who write
> libraries on LuaRocks would be interesting. Those
> who follow the dedicated mailing list know we've
> started discussing the next rockspec format and maybe
> a merge with LuaDist...

That certainly would be interesting.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Why Lua is not more popular

Roberto Ierusalimschy
In reply to this post by Tim Hill
> Well, I'm really not sure how you measure "popular". Lua is an embedded language and thus often is not "visible" even when critical to a project. For example, Lua is used in the UI of all Amazon Kindles .. does anyone know that?

I did not!

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Why Lua is not more popular

Pierre Chapuis
>> For example, Lua is used in the UI of all Amazon Kindles ..
>> does anyone know that?
>
> I did not!

Actually I think this is wrong.

I don't know about the most recent Kindles but afaik the UI of the Kindle
Touch is based on the Awesome WM so it probably embeds Lua.

On the other hand I do not think Lua is used in earlier versions of the
Kindle.

--
Pierre Chapuis


Reply | Threaded
Open this post in threaded view
|

Re: Why Lua is not more popular

D. Matt Placek
In reply to this post by Andrew Starks
The "no batteries included" philosophy does divide the lua / (python,perl,ruby,etc) camps, and the no batteries included camp is probably just smaller.  I work with embedded systems and I like not having a huge standard library that I have to distribute or try to trim down, or worry about figuring out what I need to add to my images when I add a package.  I love ruby too, but once you have a large set of batteries included packages, the problem is that everybody starts using them.  If I want to add a simple package it may require installing five other packages it depends on.  And batteries included is often overkill.  If I want to parse XML, I may just need a simple function to turn some subset of XML into lua tables.  I don't need a default package that exposes every nook and cranny of XML to my scripting language and gives me 5 different paradigms to choose from.

The fantastic thing about lua is that it's so easy to connect with C/C++ that I don't really care whether it comes with batteries.  If there's a library that has a C/C++ API I write a quick class to provide the functionality, have the class bound automatically into lua and boom, I have what I need in lua.  I don't have to worry about integrating some 3rd party package into my build and distribution with whatever dependencies the developer of the package thought were reasonable to have.
Reply | Threaded
Open this post in threaded view
|

Re: Why Lua is not more popular

Steve Litt
On Fri, 13 Sep 2013 11:57:50 -0400
"D. Matt Placek" <[hidden email]> wrote:

> The "no batteries included" philosophy does divide the lua /
> (python,perl,ruby,etc) camps, and the no batteries included camp is
> probably just smaller.  

I don't think the problem is the disinclusion of the batteries. The
problem is this:

* Do batteries exist for a particular job?
* Where to get the batteries I need for a particular job?
* Will the batteries work?
* Will the batteries conflict with my other batteries?

> I work with embedded systems and I like not
> having a huge standard library that I have to distribute or try to
> trim down, or worry about figuring out what I need to add to my
> images when I add a package.  I love ruby too, but once you have a
> large set of batteries included packages, the problem is that
> everybody starts using them.  If I want to add a simple package it
> may require installing five other packages it depends on.  

As a former Perl programmer, I know exactly what you mean. I'll never
forget one time at a client site, to get some stupid piece of "other
people's" software to deploy, I had to install some Perl packages from
CPAN, and doing so messed up their Red Hat installation. What a damn
mess.


> And
> batteries included is often overkill.  If I want to parse XML, I may
> just need a simple function to turn some subset of XML into lua
> tables.  I don't need a default package that exposes every nook and
> cranny of XML to my scripting language and gives me 5 different
> paradigms to choose from.

I know what you mean, but XML's a very bad example. Unless you do a
phenomenal amount of coding, any home-brew XML tweaker will depend on
the spacing and line breaking of the input XML, and that's a horrible
mess. I know, I've done it many times.


>
> The fantastic thing about lua is that it's so easy to connect with
> C/C++ that I don't really care whether it comes with batteries.  If
> there's a library that has a C/C++ API I write a quick class to
> provide the functionality, have the class bound automatically into
> lua and boom, I have what I need in lua.  

You really, really, REALLY need to document exactly how you make these
Lua wrappers for C libraries, publish it publicly, and let the Lua
website link to it.

That being said, my impression has always been that C at least (I hate
C++) doesn't have the wealth of libraries that Perl and Python do.

The other thing is, I get a little spooked when I need to use a library
that needs C compilation, not so much when I make the library, but when
it's someone else's library.

> I don't have to worry about
> integrating some 3rd party package into my build and distribution
> with whatever dependencies the developer of the package thought were
> reasonable to have.

Yeah, when I write stuff that will be used by others, I try to stay
away from 3rd party stuff that they'll need to install on an unknown
environment. If I'm going to use a third party lib, it's for something
I really can't do myself, like parsing HTML.

Thanks,

SteveT

Steve Litt                *  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance

Reply | Threaded
Open this post in threaded view
|

Re: Why Lua is not more popular

D. Matt Placek

On Mon, Sep 16, 2013 at 1:33 PM, Steve Litt <[hidden email]> wrote:
>[...]I don't need a default package that exposes every nook and
> cranny of XML to my scripting language and gives me 5 different
> paradigms to choose from.

I know what you mean, but XML's a very bad example. Unless you do a
phenomenal amount of coding, any home-brew XML tweaker will depend on
the spacing and line breaking of the input XML, and that's a horrible
mess.

Yes, but for instance I've recently done some work with libXML which handles all that.  But I don't need a "require 'luaxml'" that provides me the full access to everything libXML offers, which is way overkill.  I need maybe two or three calls into C to pass some XML to a function that uses libXml to turn XML into lua tables, which I can do in C and keep the interface between C and lua simple and minimal.


> The fantastic thing about lua is that it's so easy to connect with
> C/C++ that I don't really care whether it comes with batteries.  If
> there's a library that has a C/C++ API I write a quick class to
> provide the functionality, have the class bound automatically into
> lua and boom, I have what I need in lua.

You really, really, REALLY need to document exactly how you make these
Lua wrappers for C libraries, publish it publicly, and let the Lua
website link to it.

I really would love to but I have to work on convincing my employer to open source it.  I haven't looked closely at LuaBind, but I imagine it is very similar to that.  Basically it's a set of C++ templates that generate bindings for class instantiation and calling methods or static functions, doing all the marshalling between lua and C/C++ automatically.  If I was starting today I would probably use LuaBind, but at the time I began there wasn't anything like that available.


That being said, my impression has always been that C at least (I hate
C++) doesn't have the wealth of libraries that Perl and Python do.

Sure, Perl/Python/Ruby have a lot of libraries that are fully implemented in the native language, but a lot of what people look at on the question of "Does it have lots of libraries?" will be bindings to C /C++ libraries.  And that matters with Perl/Python/Ruby because writing a binding is a mess, and requires you to use SWIG or some other awful tool.  The simple stack based interface between Lua and C makes the question of whether somebody's already done it much less of an issue, even if you don't have a template library to make it even easier.

Matt
Reply | Threaded
Open this post in threaded view
|

Re: Why Lua is not more popular

Andrew Starks


On Monday, September 16, 2013, D. Matt Placek wrote:

On Mon, Sep 16, 2013 at 1:33 PM, Steve Litt <<a href="javascript:_e({}, &#39;cvml&#39;, &#39;slitt@troubleshooters.com&#39;);" target="_blank">slitt@...> wrote:
>[...]I don't need a default package that exposes every nook and
> cranny of XML to my scripting language and gives me 5 different
> paradigms to choose from.

I know what you mean, but XML's a very bad example. Unless you do a
phenomenal amount of coding, any home-brew XML tweaker will depend on
the spacing and line breaking of the input XML, and that's a horrible
mess.

Yes, but for instance I've recently done some work with libXML which handles all that.  But I don't need a "require 'luaxml'" that provides me the full access to everything libXML offers, which is way overkill.  I need maybe two or three calls into C to pass some XML to a function that uses libXml to turn XML into lua tables, which I can do in C and keep the interface between C and lua simple and minimal.


> The fantastic thing about lua is that it's so easy to connect with
> C/C++ that I don't really care whether it comes with batteries.  If
> there's a library that has a C/C++ API I write a quick class to
> provide the functionality, have the class bound automatically into
> lua and boom, I have what I need in lua.

You really, really, REALLY need to document exactly how you make these
Lua wrappers for C libraries, publish it publicly, and let the Lua
website link to it.

I really would love to but I have to work on convincing my employer to open source it.  I haven't looked closely at LuaBind, but I imagine it is very similar to that.  Basically it's a set of C++ templates that generate bindings for class instantiation and calling methods or static functions, doing all the marshalling between lua and C/C++ automatically.  If I was starting today I would probably use LuaBind, but at the time I began there wasn't anything like that available.


That being said, my impression has always been that C at least (I hate
C++) doesn't have the wealth of libraries that Perl and Python do.

Sure, Perl/Python/Ruby have a lot of libraries that are fully implemented in the native language, but a lot of what people look at on the question of "Does it have lots of libraries?" will be bindings to C /C++ libraries.  And that matters with Perl/Python/Ruby because writing a binding is a mess, and requires you to use SWIG or some other awful tool.  The simple stack based interface between Lua and C makes the question of whether somebody's already done it much less of an issue, even if you don't have a template library to make it even easier.

Matt

Easy vs. simple. The idea of binding generators has always struck me as a squishy way to get something to work now, which will be a problem when we later try to put it into production. 

Our company has integrated Lua into its asyncronous C++ API. I won't say that it was easy because it required us to try many approaches and we aren't done with that process yet.  However, we know why it's working to the extent that it is, because we took the time to learn the C API and to remake our C++ library to take advantage of it.

We would have rather hit the "easy" button and then went back to doing real work. Something this important benefitted from the work, none of which was related to trouble shooting some fragile binding generation process that didn't quite anticipate our use case, or more likely Windows. :)

Adobe's Lightroom project is interesting to me because it challenges the language choices that I normally think about: Lua vs JS vs Perl, or C++ vs Java vs C#. 

In their case, it appears that they are using Lua in its traditional role in a limited way. They are primarily replacing C++ with Lua. 

I'm very interested to know, having made it to version 5, how it feels. That is, has Lua become a giant hair ball? How does programming in Lua, to build an application, feel compared to doing that same sort of work in C++, or Java or C# for that matter. I don't think they have many projects in the later 2. 

-Andrew


Reply | Threaded
Open this post in threaded view
|

RE: Why Lua is not more popular

Dan Tull
> The idea of binding generators has always struck me as a squishy
> way to get something to work now, which will be a problem ...
I think of the half dozen or so Adobe products using Lua, a couple
of teams have tried using binding generators and none of them
were satisfied enough with the results to take that course.

What I tend to find is that bindings aren't all that hard and often
the API you want to expose to Lua isn't the one you'd get if you
exhaustively/mechanically translated it anyway.

On top of that, unless you're going to immediately use the whole
exposed API, a generator creates a large volume of dead and
untested code which has its own downsides.

> Adobe's Lightroom project is interesting to me ...it appears that
> they are using Lua in its traditional role in a limited way. They
> are primarily replacing C++ with Lua.
Lightroom's use of Lua is relatively traditional. In some ways, I think
it pushes the boundaries a bit in terms of how much of the app is in
Lua, but in other areas I think we would have benefitted from going
even further than that.

> I'm very interested to know, having made it to version 5, how it
> feels. That is, has Lua become a giant hair ball?
With the caveat that I don't work in Lightroom's codebase day to
day anymore, I would say that I don't find it to be more tangled than
other codebases of similar age and scale in other languages.

Having come from a (mostly) static language background before
joining the Lightroom team in 2006, I would have expected the
free-wheeling nature of Lua to have been more problematic in
that regard, but it really hasn't turned out that way.

It is nice to be proven wrong sometimes.

> How does programming in Lua, to build an application, feel
> compared to doing that same sort of work in C++, or Java or
> C# for that matter...
Once you have the infrastructure in place (bindings and decent
tools), I find building an app in Lua to be more pleasant and fluid
than programming in other languages.

That is mostly due to the ease of rapid iteration that is a widely
cited benefit of dynamic interpreted languages.

DT

Reply | Threaded
Open this post in threaded view
|

Re: Why Lua is not more popular

Sean Conner
It was thus said that the Great Dan Tull once stated:
> > The idea of binding generators has always struck me as a squishy
> > way to get something to work now, which will be a problem ...
> I think of the half dozen or so Adobe products using Lua, a couple
> of teams have tried using binding generators and none of them
> were satisfied enough with the results to take that course.
>
> What I tend to find is that bindings aren't all that hard and often
> the API you want to expose to Lua isn't the one you'd get if you
> exhaustively/mechanically translated it anyway.

  Another thing I've found (by doing Lua bindings by hand) is that a
mechanical approach really doesn't make for good Lua bindings.  Such a
mechanial approach to syslog() would end up with:

        syslog(5,string.format("The foo is %s",status))

Or ...

        LOG_NOTICE = 5
        syslog(LOG_NOTICE,string.format("The foo is %s",status))

Or

        syslog("LOG_NOTICE",string.format("The foo is %s",status))

Doing it by hand, I did [1]:

        syslog('notice',"The foo is %s",status)

which is MUCH nicer (IMHO) than other syslog() interfaces for Lua I've seen.

  -spc

[1] https://github.com/spc476/lua-conmanorg/blob/master/src/syslog.c


123