RE: Lua x Python

["Joshua Jensen" <jjensen@...>]

I'd like to comment on a few points made in Bruce's article:

Lua's documentation: Agreed.  Just the continual set of messages we see
on the mailing list about interfacing a C++ object to Lua or "why
doesn't print() work?" should tell us better/clearer documentation is in
order.  Despite that, the lack of _complete_ documentation is not a good
reason not to use Lua.

Python's extension modules: While I would love the wide array of
Python's extension modules in a command-line Lua scripting environment,
I would never want the overhead in a game, and this is where Bruce is
coming from.  If Lua had Python's extension modules (and that would
require a de facto way of binary loading Lua extension libraries), then
I'd say Python has NOTHING on Lua.  As it stands, this is a pretty big
win for application development (but not games, at least, not with most
of the extension modules).  It would be FANTASTIC if somebody could
write a way to call Python extension modules, much like the LuaJava
thing.

Python exceptions: I know Lua is capable of "exception-like" behavior,
but I would like to see a sample Lua script which illustrated it.

Memory allocations: Ah, the worst thing I had to deal with in Amped.  It
wasn't a bad problem to fix, since I did some upfront work to ensure
others wouldn't use features of Lua that caused memory allocations, but
it still required some clean up at the end.  There could be NO memory
allocation performed during the real-time portion of the game, because
the garbage collection took too long.  Now, I'm unsure how long Python
takes to run a garbage collection, but I'd wager it is still too long.

Performance: A quick look at http://www.bagley.org/~doug/shootout/ and
http://dada.perl.it/shootout/ tells me all I need to know about
performance.  Lua does better than Python in almost every case.  Lua
isn't as fast as other languages, but it still does well.  Looking at
these benchmarks show parts of Lua that need a lot of optimization
(should you use the feature, of course).  In the end, Python just looks
SO SLOW to me.  Real world environments may prove otherwise.  As the
matrix multiplication benchmark of Pike shows, calling C functions is
the way to go for intensive operations, but I've always been one to make
sure I'm working in a somewhat optimal environment from the beginning...

Size: Python is huge.  The core DLL is 839-ish kilobytes.  How much can
be ripped out?  I don't know, but when I can link in a 70k Lua Release
build WITH parser into my application, everybody is much happier.

Remote Debugging: I have a Lua Remote Debugger I've been using for about
two years now.  I was kind of hoping somebody else would release a good
one (so I could quit developing mine!), but I don't recall seeing any
announcements for it.  I'll see about releasing it this weekend.  The
debugger GUI only runs on Windows, though.

Consoles: Bruce's quote: "Python will end up wasting a bit of memory for
features that are not relevant on console games, but probably not enough
to worry about on the new generation of console machines, with their
minimum of 24Mbytes of memory."  Wow.  That's excellent that he had the
memory to lose.  I remember scrounging for every byte in Amped, and I
was on a 64 MB Xbox.

Legal wrangling: I had to deal with this with Lua.  With the previous
Lua license (pre-MIT), the _Microsoft_ legal department approved it.
Wow!

Disadvantages (No compile time type checking): This was the scariest
thing of all using Lua in Amped.  Of course, the realization didn't set
in until it was too late.  At one point, the end-to-end pipeline for
text display was Unicode, but over time, fell into a
Unicode->ANSI->Unicode conversion scenario.  This was bad for languages
like Japanese.  I used a modified Lua that supplied wide character
strings, and even though I didn't allow automatic ANSI-Unicode type
conversions, it took running EVERY SINGLE CASE to find all places where
ANSI strings were being used instead of Unicode.  Contrast this with the
C++ code where changing the base type automatically compile errored TONS
of code, since the ANSI-Unicode conversion had to be explicit.  This is
an extreme case for sure (and an obvious bad design), but when using a
typeless language, it takes a different mindset and an altogether
different set of error checking.  Train your programmers in this
mindset...

Lua pluses:

* Fantastic data description support.  XML should have never been
invented.  It should have been Lua instead!
* Decent C API.  It's not the best.  With my C++ wrapper, I've really
tried to shield programmers from stack management.  Having Lua stack
based at the API level does not help ease of use for programmers who
just want to use it and forget it.  (I'm sure others will disagree.)
* Speed.  For being typeless and hash-based, Lua's speed ROCKS.

Before anybody thinks I'm bashing Python, I'm not.  If it weren't for
Lua, I'd be a Python junkie.  It really is the "next best thing" for me.
Lua has a long way to go before it reaches Python's documentation level
and Python's extension libraries, but I really feel there is nothing
else about Python that is better than Lua for the things _I_ need it
for.

-Josh