[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [mildly OT] Some info about Python
- From: Lorenzo Donati <lorenzodonatibz@...>
- Date: Sun, 2 Feb 2020 11:43:37 +0100
On 01/02/2020 15:35, Andrew Starks wrote:
On Feb 1, 2020, at 06:05, Lorenzo Donati
I pointed out that some years ago Python knowledge was on par with
Lua's, whereas Lua is not even on the radar now.
(BTW, Hype /is/ a relevant market force, big companies have gone
broke for lack of good marketing at the right time).
And this is something Lua community and Lua team should be aware
In the short term, hype comes and goes, and which language gets
thrown up the charts has a lot to do with what was popular before it
and what people are rebelling against.
I share the same desire to see more people to Lua and agree that an
organized library of tested code would be helpful.
IMHO, Lua is the cleanest, simplest scripting language around. Why
do you think it is the case that after... 30+ years of Lua and
massively successful projects depending on its very unique power, it
ranks so low in the popularity list? Does the list properly represent
people that use it in commercial environments? Does it capture people
that are using Lua in roblox or in other games? (WoW, Factorio,
BeamNG Drive, ...) Does it capture embedded devices that quietly use
Lua but only say so buried in their open source statement?
I agree with what you say, but you seem to be missing my point: all the
cases you cite (IIUC) are cases of embedded Lua, i.e. Lua as a glue
language, pulling the strings of the C/C++ environment that the specific
project has set up. Those are not cases of Lua as a General Purpose
I stressed from the beginning that I'd like to see Lua used more also as
a GP-PL (and still I had no answer on whether Lua team wants that as
well). As an embedded language I just said to Roberto that I think it
has an edge over other technologies and currently is probably ahead in
That is: is Lua not popular and does it need saving?
The benefit of a standard library, independent/separated from Lua and
it’s development, is clear to me. It’s an idea that has been had
before, but why is it so hard to make it happen?
What I've seen in all these years leads me to believe that the main
1. Lack of consensus on what should constitute the library.
2. Lack of recognized coordination between committed developers.
3. Lack of structural funding for projects.
4. Lack of official blessing from Lua team.
Those factors were interwined and all participated, IMO, in the past
Something that was NOT a factor was lack of effort. On the contrary,
*there was a huge amount of (uncoordinated) effort*, which was either
wasted (see dead projects) or just ended in the creation of "a"
(standard?) library, not "the" standard library.
In a way, it reminds me the old say "Standards are good, everyone should
have its own!"
But the problem lies not in creating a library or defining an
agreed-upon API (none is perfect and none will ever be), but to convince
people that the library is:
1. stable and functionality-rich; it must solve all the most /common/
problems a GP-PL is supposed to solve /nowadays/ (math, OS interaction,
concurrency, basic web/network programming) and maybe include a FFI for
interacting with the OS in unpredictable ways that don't warrant
specific modules; it must be generally useful to both the newbie and the
professional, without being the substitute of entire applications.
2. its API is easy enough to understand in small fragments (no need of
framework-like features where one needs to learn, for example, how to
use a ton of functions before he can write an error message, parse a
command line, perform a numerical derivative or make a socket connection).
2a. newbie friendly: modules that solve simple problems should not
depend on modules that require a lot of effort to understand how to be used.
2b. modular enough so that most part of it can be stripped-off in
environments that don't need them; it should be the Lua answer to other
languages "kitchen sink approach": "you want the kitchen sink? OK, here
you go!" (no hassles, no thinking), but "Lua is better because you can
choose exactly what you want".
2c. Installation friendly: it must support simple installation,
without complex tools. Ideally one should be able to unzip a package in
a subdirectory where Lua is installed and be ready to go. This will
appeal to users (like me) that use tools from a pendrive/external HD on
different systems. It should not depend on specific tools to be
installed, i.e. LuaRocks. It's ok if it is included in LR (indeed it
should), but it should definitely support other ways of installing. In
particular, if it contains binary modules, they must be available
already compiled (at least for Windows, where the average user could not
be a C/C++ master).
2d. Easily and "dependably" expandable: it should provide upfront
policies on how a dev/company could contribute a new module, even if
they don't want to contribute with support (e.g. "Hey we developed this
module for our project, we think it's general enough to be included in
the lib; take the code, we give you all copyrights, but no dev time").
2. compatible with all widely used and /future/ version of Lua; here
comes the problem with lack of blessing/coordination: if Lua team don't
even consider to mildly coordinate with the library devs, any change of
Lua API (both Lua and Lua C-API, I mean) could create an enormous impact
on the library maintainers; moreover, if a change is not seen coming,
the time to adapt the library to the change would mean a big latency
between the new release of Lua and the release of the compatible version
of the library.
This is a big scarecrow for both users wanting to adopt the library and
library devs that have to commit to extra effort.
4. is maintained and will be maintained despite availability of single
developers; single dev efforts are doomed to fail; even small teams who
develop the library for "fun" are doomed to fail; people come and go,
and if you provide work for free you are not bound to a project in a
strong way (and rightly so). Real life can make a dev switch priority.
Someone could even lose interest in Lua (perhaps he changed his job and
has no time left to dabble with Lua?). To be a healthy project there
must be some sort of official organization (foundation?) that helps to
manage its "economical" and technical aspects (raises funds, collects
donations, curates marketing aspects, hires devs in time of need when
volunteer work is not enough, manage expenses of websites, organizes
developers' time assigned to modules development, etc., etc.). And it
must have a technical committee that decides on cases like (2d) above or
on whatever would be useful to be added.
4a. This hypothetical foundation should be driven by community, but
not ruled by community. That is, it must be created so that it must
listen to community, but then the technical decisions are to be taken by
a technical committee (Lua team members could be permanent members, if
they care, or may nominate one representative; other people should be
elected from recognized and authoritative members of the community, for
example). That's the real tricky part: choosing the right people and the
right policies to avoid falling in a dumb "design by committee" hell.
3. is the "go to" solution when no more specific needs arise; the whole
community (Lua team included) should be convinced that whenever one asks
which library to use the answer is "This library", unless there are more
specific/better alternatives. No more: "You can use penlight, or stdlib,
or this other one, but in this other there is that module that could be
useful...". (It's not a "Rule them all" approach. It's like: "Try this
first" if doesn't fit your bill ask again and we'll help you).
Sorry for the long post. That was a quick analysis and possible solution
to this recurring "library" problem. It is my opinion, of course, and it
was laid out off the top of my head given my long experience on Lua-l.
It is not meant to be a "well organized plan" to success, but I think it
highlights some of the problems that need to be overcome.
BTW, to @Sean Conner (to which goes all my admiration for his expertise
and committment, now and in the past years): I really appreciate your
effort in trying to define an API, but (sorry to be blunt) I think you
are making the same mistake others have made in the past.
You started designing to solve the problem "let's create the core of the
library", whereas I think we have a bigger problem: we first need
policies and organization (what Lua and Lua team by design don't offer).
Yes, I know that itch: "OK (*...he says, pulling up his sleeves ...*)
let's crack this nut open!". We as developers love to solve technical
problems, and sometimes we lose the bigger picture.
The "we have no standard library" issue is not a technical problem in
the first place, but a management and (partly) a social one, IMO.