Re: it's a shame about voodoopad

["E. Wing" <ewmailing@...>]

On 11/6/09, Sam Roberts <vieuxtech@gmail.com> wrote:
> On Fri, Nov 6, 2009 at 12:53 AM, Matthew P. Del Buono
> <delbu9c1@my.erau.edu> wrote:
>> Despite the fact that I can't really change their decision, especially
>> without giving hard facts, I find it interesting to point out that they
>> seem to be going in the exact opposite direction as everyone else. I
>> personally feel (and a few coworkers have brought this up too,
>> independently) that Lua is rapidly replacing Python as the premier
>> choice in embedded scripting languages for applications. Why they are
>> choosing to move back to Python seems to be beyond me. In fact, based
>> off your quote (I haven't done research myself), it seems to be based
>> mostly off a personal opinion and off no hard facts whatsoever.
>
> Yeah, but the voodoopad author actually put significant time and
> energy into integrating lua, it's his opionion, but its based on a
> fair bit of experience.
>
> I think that one of two things might have happened.
>
> lua is great if most of  the code you write interacts with the app you
> are embedded in. Examples of this would WoW, nmap, wireshark, etc. You
> don't write lua code in a wireshark dissector that interacts with the
> world, all it can do is call back into the lua core libraries, and the
> wireshark libraries. lua is perfect here.
>
> But, if you want to write code that half interacts with the app, and
> also interacts with the outside world, maybe it does xmlrpc calls to
> get info, maybe it starts up a mini web server or stores things in
> mysql, etc., then the fact that lua is library poor starts to matter,
> and the fact that your users might already know how to do all those
> things in python starts to matter.
>
> I think that's what happened to voodoo pad, he's trying to use the
> embedded language to integrate external libraries into his app.
>

Actually, I bet the problem is more fundamental. Last I checked, his
code was based on LuaObjCBridge which is horribly out of date. It is
not Objective-C 2.0 ready among other things and thus will prevent his
application from being 64-bit.

I am in the middle of writing a new next generation Lua/Objective-C
bridge using all the modern things the other bridges use like
BridgeSupport and libffi to fix these problems plus do things that the
old bridge didn't do well like functions, structs, constants, etc. But
it's not done yet. (Though there are lots of things it can do already
that the old bridge could not.)

But whether this will be enough to convince him to re-adopt Lua is
another matter. And my bridge is pretty much a rewrite with new APIs
and behaviors, so it will not be a drop-in replacement for the old
bridge. (And I don't know how much longer it will take me to finish
the new bridge (maybe I need to recruit?). Chances are he will ship
before I finish.)

-Eric