lua-users home
lua-l archive

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




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

On Mon, Sep 16, 2013 at 1:33 PM, Steve Litt <slitt@troubleshooters.com> 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