From Lua to Python?

classic Classic list List threaded Threaded
79 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: From Lua to Python?

Petri Häkkinen

> On 13.7.2017, at 16.48, Dibyendu Majumdar <[hidden email]> wrote:
>
>
> Actually OO is essential tool for organizing large code bases. I am
> not talking about inheritance and all - but just the ability to
> organize your code into objects of different types.

This is such a common fallacy that it's giving me the shivers. For example take a look at Linux source code for a very large codebase written by very large team without OO.
 

I think that the 20 years I spent in OO land was a terrible mistake. OOP leads into overarchitecting, poor performance (too much focus on small individual objects rather than data flow) and longer development times (design paralysis).

Petri
Reply | Threaded
Open this post in threaded view
|

Re: From Lua to Python?

Dibyendu Majumdar
Hi Petri

On 14 July 2017 at 09:28, Petri Häkkinen <[hidden email]> wrote:

>
>> On 13.7.2017, at 16.48, Dibyendu Majumdar <[hidden email]> wrote:
>>
>>
>> Actually OO is essential tool for organizing large code bases. I am
>> not talking about inheritance and all - but just the ability to
>> organize your code into objects of different types.
>
> This is such a common fallacy that it's giving me the shivers. For example take a look at Linux source code for a very large codebase written by very large team without OO.
>

Hmmm, you are comparing Lua with a statically typed language C which
is not a valid comparison. In C, the kind of OO I am talking about is
prevalent - such as take stdio. The FILE* is the object. Because of
static type checking a function call syntax works fine. In Lua, this
is errorprone as it is a dynamic language - so an API that asks users
to say file:write() helps the user to avoid mistakes.

>
> I think that the 20 years I spent in OO land was a terrible mistake. OOP leads into overarchitecting, poor performance (too much focus on small individual objects rather than data flow) and longer development times (design paralysis).
>

Sure, but OO is a big topic and I was only talking about very basic
object / message passing type design that helps building APIs in a
dynamic language like Lua.

Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: From Lua to Python?

Petri Häkkinen

> On 14.7.2017, at 23.40, Dibyendu Majumdar <[hidden email]> wrote:
> Hmmm, you are comparing Lua with a statically typed language C which
> is not a valid comparison. In C, the kind of OO I am talking about is
> prevalent - such as take stdio. The FILE* is the object. Because of
> static type checking a function call syntax works fine. In Lua, this
> is errorprone as it is a dynamic language - so an API that asks users
> to say file:write() helps the user to avoid mistakes.

In practice I've not found ':' to be any less error prone. It's easy to accidentally type '.' in its place so you are trading one mistake for another.

In practice though, after you have dropped the magical self notation and start thinking outside the realm of objects and classes, you began to wonder why you ever needed ':' in the first place. It begins to feel very artificial to have one biased function arg when you really just have functions operating on its args. Also not needing to shoehorn every operation into a class, was a real eye- opener for me.

Petri

Reply | Threaded
Open this post in threaded view
|

Re: From Lua to Python?

Petri Häkkinen
In reply to this post by Dibyendu Majumdar

> On 14.7.2017, at 23.40, Dibyendu Majumdar <[hidden email]> wrote:
> In Lua, this
> is errorprone as it is a dynamic language - so an API that asks users
> to say file:write() helps the user to avoid mistakes.

Actually, how is file:write("abc") any less error prone than say shb_file_write(file, "abc")?  (Example from my Shinobi game engine)

In both cases it's just as easy to have a typo in "file" arg. Having the ':' in the OO case actually makes it more error prone because of the ':' vs. '.' syntax.

Petri
Reply | Threaded
Open this post in threaded view
|

Re: From Lua to Python?

Dirk Laurie-2
In reply to this post by Petri Häkkinen
2017-07-15 7:13 GMT+02:00 Petri Häkkinen <[hidden email]>:

>> On 14.7.2017, at 23.40, Dibyendu Majumdar <[hidden email]> wrote:
>> Hmmm, you are comparing Lua with a statically typed language C which
>> is not a valid comparison. In C, the kind of OO I am talking about is
>> prevalent - such as take stdio. The FILE* is the object. Because of
>> static type checking a function call syntax works fine. In Lua, this
>> is errorprone as it is a dynamic language - so an API that asks users
>> to say file:write() helps the user to avoid mistakes.
> In practice though, after you have dropped the magical self notation
> and start thinking outside the realm of objects and classes, you began
> to wonder why you ever needed ':' in the first place. It begins to feel
> very artificial to have one biased function arg when you really just
> have functions operating on its args. Also not needing to shoehorn
> every operation into a class, was a real eye- opener for me.

We're off-topic, which for this partuclar topic is fine with me, and
since the OP is a major culprit, I guess it is fine with him too.

OO has its uses, but is not the cure-all solution to every problem.
What I like about OO in Lua is that you can use exactly as much
of it as you need. We've got polymorphism anyway, without any
metatables, so one of the big arguments for OO is irrelevant.
You want to separate data and methods? Use an __index
metamethod. Encapsulation, inheritance? All possible, but it
is a good idea to read "Programming in Lua" before you start.

On the other hand, if you have a userdata then OO is clearly
indicated. You have to create a method table anyway, and the
whole point of that table is to supply access methods, so there
is always one special argument.

Files are userdata. The Lua string type is for all practical purposes
a predefined userdata, so having 'string' as its __index metamethod
makes compelling sense.

Tables ... this gets gray. I sometimes feel I need OO in order to be
able to hide it. I.e. I write a polymorphic global function that does
the object-oriented calls (modelled on 'pairs', 'tostring' etc).

-- Dirk

Reply | Threaded
Open this post in threaded view
|

Re: From Lua to Python?

Sean Conner
In reply to this post by Petri Häkkinen
It was thus said that the Great Petri Häkkinen once stated:

>
> > On 14.7.2017, at 23.40, Dibyendu Majumdar <[hidden email]> wrote:
> > In Lua, this
> > is errorprone as it is a dynamic language - so an API that asks users
> > to say file:write() helps the user to avoid mistakes.
>
> Actually, how is file:write("abc") any less error prone than say
> shb_file_write(file, "abc")?  (Example from my Shinobi game engine)
>
> In both cases it's just as easy to have a typo in "file" arg. Having the
> ':' in the OO case actually makes it more error prone because of the ':'
> vs. '.' syntax.

  It allows for a form of type substitution.  I can write a function like:

        function copy(to,from)
          local data = from:read(8192)
          if data then
            to:write(data)
            return copy(to,from)
          end
        end

and as long as the from parameter supports read() and the to parameter
supports write(), it won't really matter if to and from aren't a FILE*
userdata.

  -spc


Reply | Threaded
Open this post in threaded view
|

Re: From Lua to Python?

Dibyendu Majumdar
In reply to this post by Javier Guerra Giraldez
On 13 July 2017 at 12:07, Javier Guerra Giraldez <[hidden email]> wrote:
> On 13 July 2017 at 10:44, Dibyendu Majumdar <[hidden email]> wrote:
>> I am not sure what has propelled Python to this spot - perhaps the
>> adoption by Google several years ago.
>
>
> I think part of the merit is in NumPY library.

So I have been trying to understand if there is something about Python
that apart from the availability of NumPY makes it more attractive to
numeric users than Lua.

I asked a few weeks ago what Lua users thought about having a distinct
array type (http://lua-users.org/lists/lua-l/2017-06/msg00299.html)
but responses indicated no one thought this was important.

However, as I learn Python, I am finding a few things pretty useful
for certain types of programming needs.

1) First the existence of arrays - an array is fundamentally different
from a Lua table as it has certain guarantees. In particular it is an
ordered set, with no holes, and has efficient indexing and length
operations. Lua tables cannot efficiently provide these guarantees (I
am not including LuaJIT into consideration here).

2) Array slicing operations.

3) Ability to specify multiple operands in array indexing []
operation. In Python you can write a[1,2] - which is convenient for
accessing matrices - and you can go higher dimensions. The syntax is
natural. But comparatively in Lua the indexing operation takes a
single argument. Of course you can pass a table as argument but
syntactically that is ugly - apart from the inefficiency (although
Python is probably no more efficient). One can use the call () syntax
but that introduces inconsistency as well.

I have always wished I could support at least [x,y] syntax in Ravi.
Recently after using Python I have begun to think that maybe I could
do this by adding a new type in Ravi - <integer-pair> - which would be
a pair of 32-bit integers. This can fit into the Lua value structure
nicely - and would allow indexing operation to take two integer
arguments. It could even be extended to a tuple of three 32-bit
integer values - useful for representing slicing operations.

Anyway - I have no enough evidence for this yet - but my gut feel is
that the lack of a distinct array type could be a factor with Lua's
popularity in certain domains.

Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: From Lua to Python?

szbnwer@gmail.com
i came from python land, and i'm feeling much better with lua tables.
it's already enough complexity to having metatables, when i wanna make
universal tools for 'structures' (table in table; so i mean tree,
matrix or whatever; just as well as anything else hierarchical around,
like directories). array, dict and tuple were too much differentiated
for me. - but this is me with my own goals, i can understand the
reason behind that way, just i dislike it as it makes everything that
much more complex. so in big, anything universal becomes that much
more heavyweight and complex. lua is way much better for
metaprogramming, as i think there probably i have to go with oop
stuffs if i wanna get polymorphism, and that is a higher level of
complexity. additionally i have no idea about how could those * and **
function calls for array and dict ever become universal. it's kinda
overengineered to make universal stuffs, or if it's possible, it will
be that much more complex always. however for a straight aim, stuffs
of python are fine as specialized right that way.

i've used python too far back in time, so sorry if i've just said
anything bullshit :D but on the other hand i know i wasn't enough
clean in expressing myself and what i'm thinking behind my probably
imprecise wording, but i can feel very deep difference for the good of
lua, even if my python knowledge was good, but i wasn't as much good
with codes as currently, and my python knowledge became dusty for
now...

Reply | Threaded
Open this post in threaded view
|

Re: From Lua to Python?

Dirk Laurie-2
In reply to this post by Dibyendu Majumdar
2017-07-15 14:01 GMT+02:00 Dibyendu Majumdar <[hidden email]>:

> On 13 July 2017 at 12:07, Javier Guerra Giraldez <[hidden email]> wrote:
>> On 13 July 2017 at 10:44, Dibyendu Majumdar <[hidden email]> wrote:
>>> I am not sure what has propelled Python to this spot - perhaps the
>>> adoption by Google several years ago.
>>
>>
>> I think part of the merit is in NumPY library.
>
> So I have been trying to understand if there is something about Python
> that apart from the availability of NumPY makes it more attractive to
> numeric users than Lua.
>
> I asked a few weeks ago what Lua users thought about having a distinct
> array type (http://lua-users.org/lists/lua-l/2017-06/msg00299.html)
> but responses indicated no one thought this was important.
>
> However, as I learn Python, I am finding a few things pretty useful
> for certain types of programming needs.
>
> 1) First the existence of arrays - an array is fundamentally different
> from a Lua table as it has certain guarantees. In particular it is an
> ordered set, with no holes, and has efficient indexing and length
> operations. Lua tables cannot efficiently provide these guarantees (I
> am not including LuaJIT into consideration here).

I don't miss arrays at all. Lua does a good job. What I do miss are
tuples, i.e. constant arrays (not the same as Lua tuples).

In Lua, x[{1,2,3}] is legal, but not equal to another x[{1,2,3}.
In Python, x[[1,2,3]] is illegal, but x[(1,2,3)] is legal and
equal to another x[{1,2,3}].

Reply | Threaded
Open this post in threaded view
|

Re: From Lua to Python?

szbnwer@gmail.com
> I don't miss arrays at all. Lua does a good job. What I do miss are
> tuples, i.e. constant arrays (not the same as Lua tuples).
>
> In Lua, x[{1,2,3}] is legal, but not equal to another x[{1,2,3}.
> In Python, x[[1,2,3]] is illegal, but x[(1,2,3)] is legal and
> equal to another x[{1,2,3}].

that can be implemented with a function that returns an identity

Reply | Threaded
Open this post in threaded view
|

Re: From Lua to Python?

Tom Cook
I'll throw my $0.02 of experience in here.  This is from a couple of years ago so sorry if anything's out of date.

I wrote a testing tool a few years back that had some unusual requirements.  It had to have a web front-end, database integration, data storage and retrieval, some code that ran in (reasonably) hard real time, integration of user-supplied scripts in the real-time segment and a limited tendency to crash.

We ended up with a python application with a portion written in a C++ library, which in turn integrated Lua for user scripting.  The C++ library kicked off a new thread that contained all the hard(ish) real-time stuff and used the Lua library for user scripting.

Lua was almost the only choice for scripting in the real-time context because it's about the only scripting language that has a non-stop-the-world garbage collector.  It is also one of fairly few languages where it is relatively easy to run a user script in a locked-down sandbox.  It would have been very difficult or impossible to meet either of these requirements in Python.  We could have done the scripting in Python or C# or Java, but the garbage collector would have ruined the timing every now and then.  We could have done it in C but the thought of compiling user-supplied C code and running it on our device made me want to chew my own leg off.

On the other hand, we chose python to do all the housekeeping, web front-end, database integration and data retrieval.  It's a little bit harder to say exactly why, but this still feels like it was the right choice.  Partly it's that it's just easier to find people who know Python and we already had some Python experience in-house whereas we all had to learn Lua from scratch.  Partly it's that it's really easy to install Python libraries to do everything we wanted - and again familiarity counted here.  We all already knew Python web frameworks.  Yes, Lua has them too, but that would have meant learning and there was no compelling reason to do all that in Lua.

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.

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?

Regards,
Tom



On Sat, 15 Jul 2017 at 13:50 [hidden email] <[hidden email]> wrote:
> I don't miss arrays at all. Lua does a good job. What I do miss are
> tuples, i.e. constant arrays (not the same as Lua tuples).
>
> In Lua, x[{1,2,3}] is legal, but not equal to another x[{1,2,3}.
> In Python, x[[1,2,3]] is illegal, but x[(1,2,3)] is legal and
> equal to another x[{1,2,3}].

that can be implemented with a function that returns an identity

Reply | Threaded
Open this post in threaded view
|

Re: From Lua to Python?

Coda Highland
On Mon, Feb 5, 2018 at 4:56 AM, Tom Cook <[hidden email]> wrote:
> Lua was almost the only choice for scripting in the real-time context
> because it's about the only scripting language that has a non-stop-the-world
> garbage collector.

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.

> 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.

> 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.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: From Lua to Python?

Dibyendu Majumdar
In reply to this post by Tom Cook
Hi,

On 5 February 2018 at 10:56, Tom Cook <[hidden email]> wrote:
> We ended up with a python application with a portion written in a C++
> library, which in turn integrated Lua for user scripting.  The C++ library
> kicked off a new thread that contained all the hard(ish) real-time stuff and
> used the Lua library for user scripting.
>

This matches my conclusion as well - Lua is better when you need a
language in an app to provide user scripting.

For general purpose app development it is the Python's large library /
eco system that wins it for Python; also Python is arguably a more
user friendly language (less DIY).

Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: From Lua to Python?

Tom Cook
In reply to this post by Coda Highland
On Mon, 5 Feb 2018 at 16:56 Coda Highland <[hidden email]> 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.

Regards,
Tom
Reply | Threaded
Open this post in threaded view
|

Re: From Lua to Python?

Franz Fellner


2018-02-06 16:06 GMT+01:00 Tom Cook <[hidden email]>:
On Mon, 5 Feb 2018 at 16:56 Coda Highland <[hidden email]> wrote

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.

Does https://github.com/ThePhD/sol2 look better to you?

Reply | Threaded
Open this post in threaded view
|

Re: From Lua to Python?

Tom Cook
On Tue, 6 Feb 2018 at 15:17 Franz Fellner <[hidden email]> wrote:
2018-02-06 16:06 GMT+01:00 Tom Cook <[hidden email]>:
On Mon, 5 Feb 2018 at 16:56 Coda Highland <[hidden email]> wrote
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.

Does https://github.com/ThePhD/sol2 look better to you?

At a glance, yes it certainly does.

Regards,
Tom 
Reply | Threaded
Open this post in threaded view
|

Re: From Lua to Python?

Coda Highland
In reply to this post by Tom Cook
On Tue, Feb 6, 2018 at 9:06 AM, Tom Cook <[hidden email]> wrote:

> On Mon, 5 Feb 2018 at 16:56 Coda Highland <[hidden email]> 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.

That's saying the same thing I said with more precision. (Of course,
even the incremental collections have to stop the world; the idea is
to keep those as brief as possible.) The thing is, ALL garbage
collectors CAN hit pathological cases where you end up taking a long
time to clean up (the alternative is to leak memory), and Lua's is no
exception to that. The best you can do -- and Lua does a really good
job of it -- is to try to make the pathological case not come up for
typical patterns of use.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: From Lua to Python?

Russell Haley
In reply to this post by Tom Cook
On Tue, Feb 6, 2018 at 7:06 AM, Tom Cook <[hidden email]> wrote:

> On Mon, 5 Feb 2018 at 16:56 Coda Highland <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: From Lua to Python?

Russell Haley
On Tue, Feb 6, 2018 at 11:55 AM, Russell Haley <[hidden email]> wrote:

> On Tue, Feb 6, 2018 at 7:06 AM, Tom Cook <[hidden email]> wrote:
>> On Mon, 5 Feb 2018 at 16:56 Coda Highland <[hidden email]> 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).

Also for reference, a smallish System On A Module (SOM) I possess has
512 MB raw NAND, 1gb eMMC, and 512MB ram. It's a Freescale iMX53,
which is a single core Cortex A8. The board is called a Digi CCWMX53
(I think...).

> 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

1234