lua-users home
lua-l archive

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


> 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