Re: [mildly OT] Some info about Python

[Steve Litt <slitt@...>]

On Sat, 18 Jan 2020 16:05:29 +0100
Lorenzo Donati <lorenzodonatibz@tiscali.it> wrote:

> On 17/01/2020 09:03, Marc Balmer wrote:
> >
> >  
> >> Am 15.01.2020 um 16:59 schrieb Lorenzo Donati
> >> <lorenzodonatibz@tiscali.it>:
> >>
> >> Hi all!
> >>
> >> On a recent thread ("Dead Batteries" ) I argued that Lua lost
> >> terrain over Python.
> >>  
> [ snip]
> 
> >
> > I usually pick my tools to fit the work at hand, not by means of
> > what is currently en vogue...
> >  
> 
> Exactly!
> 
[snip]

> One could argue ad infinitum, but the hard data show that more and
> more people find Python solves their problems "better" [1] than Lua.
> And Lua is losing user base on a daily basis (at least in relative
> numbers).
> 
> [1] "better" meaning: more readily, more thoroughly, more rapidly,
> more whatever. Heck! They might not even know Lua exists for what
> matters.

The preceding assertion, which I agree with in a limited context, is,
in my opinion, the most important in this email. I'd like to paraphrase
the preceding assertion as "If you start a project in Python, you're
more likely to finish it in Python as opposed to if you'd started it in
Lua and expect to finish it in Lua."

More on that later...


[snip several similar assertions and arguments]
 
> 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.

[snip]

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

This thread was spawned by the "Dead Batteries", but this particular
post takes no position on "batteries" (a well curated standard Lua
library). This email could be taken one of two ways:

1) Python's more likely to solve your problem because and only because
   Python has "batteries" and Lua doesn't, so Lua batteries are
   necessary and sufficient to make Lua preferable for most programming
   than Python, so Lua should acquire batteries.

2) Python's more likely to solve your problem because and only because
   Python has "batteries" and Lua doesn't, so because Python's more
   likely to solve your problem, Lua should confine itself to embedded,
   where Python just can't go, and not bother with batteries.

In my opinion #2 is circular thinking non-logic.

By the way, it's not just Python. I've been studying Tcl for the last
ten days. Tcl has "batteries" galore, they're in one standard library
package that's separate from the Tcl package itself, and so far I've
found they all work perfectly except for the Huddle object
(serialization). Even though I just started Tcl, because of batteries,
I'd be more confident of starting a difficult project in Tcl than in
Lua.

IMHO in this day and age, you need a language that can easily and
reliably and without experimentation interact with XML, HTML(5), Xhtml,
databases, JSON, YAML, DOM, sockets, IPC, complex numbers, and probably
twenty other things I haven't thought of yet. And with small appliance
devices doing ever more mainstream things, some of these batteries will
probably become more important, in embedded programming, in the future.

So, in my opinion, Lua would greatly benefit from an official, blessed,
curation of libraries available both in a single package for when disk
space isn't at a premium, and a-la-carte for embedded.

SteveT

Steve Litt 
January 2020 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust