 |
lua-l archive |
|
|
||
|
On 01/02/2020 15:35, Andrew Starks wrote:
On Feb 1, 2020, at 06:05, Lorenzo Donati <lorenzodonatibz@tiscali.it> wrote: 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 of, IMO.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 Programming Language.
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 usage.
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 reasons are:
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 failures.
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.
Cheers! -- Lorenzo