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.
