Re: [mildly OT] Some info about Python

[Sean Conner <sean@...>]

It was thus said that the Great Lorenzo Donati once stated:
> On 17/01/2020 09:03, Marc Balmer wrote:
> 
> >I usually pick my tools to fit the work at hand, not by means of what
> >is currently en vogue...

  So does that mean you use Fortran for numerical analysis, COBOL for your
business logic, Perl for text munging and Intercal for job security?  What
exactly does it mean to pick the tool (programming language or tech) for the
work at hand?  In my own cynical way, I tend to think it's said more by tool
mavens with a preference towards hipster views followed by what is popular.

> Exactly!
> 
> And what I reported seemed to indicate that a great majority in the 
> world find Python more apt at solving their problems than Lua.
> 
> Unless you think all those Python programmers/users are funny people 
> that choose a language using the criteria they would when choosing a 
> fancy new scarf.

  Yes, pretty much.  It's popular, so I must learn it.  Who uses Lua?  Why
bother with Lua when that limits my job prospects.

  On the other hand, going with Python (or any other hip new popular
language like Go) you are now competing against scores of other programmers
who know just as much as you do.  The Lua jobs might be few and far between,
but I stand a better chance of landing them that a Python programmer.

  But who thinks like that?

> Ask yourself: would you (a company) prefer a Python solution that is 
> bloated and slow, but still "fast enough", well supported (because 
> "everyone" know Python) and that is created in 10 days, or an equivalent 
> Lua solution that takes 2 month to be created and that cannot be 
> supported long term because you don't even know where to find an 
> alternative Lua dev in your area would the need arise? Not to mention 
> the level of support of libraries.

  It's funny you mention that.  I used Lua for a few projects at work (one
is very imporant (such that it's the front end to the actual product that
generates *all* our profit at the company) and yet, I'm only one of two
programmers there that know Lua.  Our QA engineer keeps using Python for
running tests because he finds it easier to use than Lua (despite the fact
that most of our testing tools I've written were in Lua when I was in the QA
department).

  Changes to my part of the codebase usually take on the order of hours, not
days or even a few weeks like some other parts (written in C and C++).  I
mainly attribute that to Lua's coroutines, since the main logic of the
program (which is event driven using select() [2]) looks more like
imperative code than chopped up callback hell or asynchronous promises or
whatever the new hotness is in nodejs these days.

  Also, back in late 2018, a new project was announced.  I (by myself, on my
own) managed to write 90% of the code base in Lua in two days (the last bit
wasn't done because of some still open questions).  The other team that
actually started writing the code took the better part of a year (I
think---I'm not entirely sure they're done yet) to write the program.  But
hey, I program in Lua, what so I know?

> Again, Lua is better at some things, but that doesn't make it a "good" 
> general purpose PL (and being Turing complete doesn't count in practice) 
> if people don't /use/ it as a GP-PL.
> 
> And, btw, this huge user base means that Python use is growing even in 
> areas where Lua definitely shine: embedding. I find more and more 
> projects that use Python as embedded language. I can't say how difficult 
> is to embed Python, but I'm sure that if the demand grows, someone in 
> the Python community will find a way to make it simpler.

  And here I thought that Python was shedding users to Go, because of
similar easy of use plus it runs faster (and is just as opinionated, if more
so, than Python).

> I really think Lua Team should reconsider some of their positions on the 
> development model of Lua, otherwise they risk a slow descent into 
> irrelevance in the PL landscape in a couple of years (except maybe some 
> very limited niches).

  They might not even care.

  -spc (Never been one to use the popular stuff ... )

[1]	https://blog.osteele.com/2004/11/ides

[2]	Well, poll() actually on the production server, epoll() on Linux and
	kqueue() on Mac, but the later two are mostly test platforms.