[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Upstream is not the last word (was Re: [ANN] Lua 5.1.5 (rc1) now available)
- From: Sean Conner <sean@...>
- Date: Tue, 14 Feb 2012 03:39:56 -0500
It was thus said that the Great Ross Bencina once stated:
> I'm going to attempt an answer, from my perspective:
> Use case #1: application development language
[ snip ]
> Use case #2: user extension language
[ snip ]
> For use case #1 above (developing) it probably doesn't matter, people
> can do what they like, but for use case #2 (user extension) I really
> don't want to wear the "object system and language library designer" hat
> and be held accountable by my users of how such basic facilities work --
> I'm more than happy to do it the "standard base way".
> Does that make sense?
Not really. I don't see any real difference between #1 and #2, so I'm not
even sure what you are asking. Also, I'm not a big proponent of object
oriented programming, and I find what Lua provides just fine for my own
needs (I stay as far away from C++ as possible), so I don't quite understand
this whole obsession over objects. From what I can see, Lua support of
"objects" is fine.
At work, I use Lua to test our software. And for one platform (Solaris)
I've had to create what I call "The Kitchen Sink Lua"---it's basically a
custom Lua standalone interpreter that has all the modules we need to run
(both in C and Lua) built into a single executable. And yes, stuff that
would normally go into /usr/local/lib/lua/5.1 or /usr/local/share/lua/5.1
have been compiled statically into this "Kitchen Sink Lua" (primarily
because it's difficult to get the required shared objects/Lua files
installed on the deployment systems).
So for my use case, it's important to be able to statically compile
modules into the program. It's less important to have a "base library" or
"base object system" because what Lua provides is enough (or rather, I have
to supply quite a bit, but it's all custom coding anyway).