Re: From Lua to Python?

[Russell Haley <russ.haley@...>]

On Tue, Feb 6, 2018 at 7:06 AM, Tom Cook <tom.k.cook@gmail.com> wrote:
> On Mon, 5 Feb 2018 at 16:56 Coda Highland <chighland@gmail.com> wrote:
>>
>> Lua's GC stops the world. All garbage collectors do. Lua's is just
>> reasonably well-behaved and tries to avoid big sweeps as much as
>> possible by doing smaller collections more often. It's also easier to
>> write Lua code that generates less garbage. And if you're doing
>> one-state-per-thread (the recommended way of doing it) then you're
>> only blocking one thread instead of the world.
>>
>
> I am no expert on the ins-and-outs of garbage collection, but I understand
> this is not the case - see http://lua-users.org/wiki/LuaInRealTimePrograms.
>
>> > Perhaps the biggest difference is that integrating C++ code with Python
>> > is
>> > light years easier than integrating C++ code with Lua.  Boost::Python
>> > makes
>> > it all so, so easy, while trying to keep a ten-deep stack straight in
>> > your
>> > head on the Lua side was an endless source of defects.  Again, there
>> > might
>> > be something out there that does all this for you in Lua too, but we
>> > didn't
>> > know about it or find it.
>>
>> You just didn't look far enough. There are several Lua frameworks for
>> C++ integration. lua-primer and luabind come up as the first two hits
>> in a Google search.
>
>
> Well, so we didn't look far enough.  On a quick inspection, neither of those
> look nearly as good as boost::Python, but that might be an aesthetic thing.
>
>>
>>
>> > Regarding some of the accusations of "bloat" against the Python
>> > libraries
>> > above - of course this is perfectly true.  But I'm not sure why it
>> > matters.
>> > That "bloat" doesn't cost you at runtime unless you use it - when it
>> > becomes
>> > useful library, not bloat.  So unless you're trying to install this on
>> > decades-old computer where disk space is a serious issue, what is the
>> > cost
>> > of that bloat?
>>
>> Embedded systems are modern but have serious disk space constraints.
>> Also the presence of those libraries as "standard" means the ecosystem
>> depends on them, so you never know when one of your dependencies is
>> going to pull those in and start using up RAM as well. It's not a
>> horrible cost, but it's something to be aware of, and Python is a
>> fairly slow language to begin with. It's still a fantastic tool, but
>> if you're comparing it to Lua, then that's one of the things to look
>> at.
>>
> I work almost exclusively in modern embedded systems.  It's been a long time
> since I've come across one where either volatile or non-volatile storage is
> a serious constraint.  Yes, we're careful about how we use it in
> deterministic code, but the actual amount available is almost never a
> constraint.  There is still a lot of kit out there that does have these
> constraints, so maybe I'm lucky that I haven't been required to work with
> old hardware for a long time.

There are amateur type, low-level hardware kits that exclusively use
Python as the development interface. It's all very do-able but... IMHO
anything using smaller than an Armv5 system with Python starts to
become problematic. From what I understand the instruction sets are
*very* limited and that causes problems for languages like Python. For
reference, Cortex A8/Armv6 is about the smallest most companies use
now unless it's dedicated/custom hardware (done lots of peering into
competitors and custom display systems).

I have limited knowledge of Python, but I think like most languages,
it's probably fast enough until someone decides to create a library to
help the developer out. Then, overhead starts to creep into the
equation. From what I've seen with Python, it's all about the helper
libraries.

What validated my decision to use Lua was that OpenWRT runs on routers
with *very* small memory modules (volatile and non-volatile). From
what I understand it uses Lua exclusively for interfacing with the OS
and other subsystems. I don't think I'd try running a router with
Python. :)

Russ