In general I agree with the idea, but I see a big problem: Lua simply lacks a unified community mindset as many other languages have. From what I've seen, I see a few large groups that most Lua users can broadly be categorized into: 1. Uninterested scripters: That is, people who don't care about Lua or its more complex features. Usually there are either Developers that have found their language and are happy with it, and only use Lua to script certain programs and therefore don't care much for the state of the language, and users that are new to programming that have to use Lua because some application (in most cases games or game engines) happen to be scripted in it. This second subgroup seems to have a strong tendency towards cargo cult programming and many would rather have code written for them and want to get by with the absolute minimum of understanding. 1.1 Python scripters. This group can safely be ignored without side effects. /s 2. Hermit programmers who use Lua, but otherwise don't really interact much with the community. I don't think anybody really interacts with the entire Lua commumnity, considering how spread out it is, but some people just have a particularly small interest in it. 3. Lua enthusiasts that see something special in the language and prefer using it to many if not all of the alternatives and who enjoy exchanging thoughts on the language. This probably applies to most people in this list. 4. Developers that have chosen Lua for one or several projects, not necessarily because they particularly like it, but because they've considered the options and Lua was just the best suited option for the given project. I would assume most people in the previous group have gone through (or are still part of) this group. So to me the main problem seems to be that it's mostly the third group that is most likely to contribute code to the community, as they're the only users that have any sort of personal interest in the growth of the Lua ecosystem as a whole. And going by reddit, discord and stackoverflow, they're the smallest but most active part of the community. It doesn't happen often that someone who always just wanted to build something in roblox ends up helping newcomers with problems that they've also faced in the past; usually it's the same few users, who've never touched roblox even once, who end up trying their best to get the problem solved. So, with that being the problem, how could it be solved? In a perfect world, we'd just win over more people into the third group by showing the everyone how nice Lua is and why it's better than whatever they're using, but that's just not very realistic. If we want more of the third group, we first need more of the fourth group, but what we're getting is mostly the first group. So the alternative would be to somehow capture more of the users that really only pick up Lua for some very specific task. The problem with this is that, sadly, many Lua APIs are just trash. There's a world of globals, ad-hoc code and poorly translated pythonisms out there, and not many examples of idiomatic, well-designed APIs to offset it all. This leaves us with one very sad conclusion: No help is coming. There won't be any reinforcements. So then the question is, are there enough of us with enough know-how, time and motivation to really build a broad set of libraries that cover about as much ground as the ruby STL *and* at least a few unique features so Lua isn't just on the same level, but actually goes beyond its alternatives, at least in one domain, but ideally in quite a few? Those are my thoughts anyway. I've tried organizing it a bit, but it's still somewhat /stream of consciousness-/esque. On 20/01/2020 10:41, Rodrigo Azevedo wrote: > Motivated by recent discussions about standard libraries and codes, I > have the following considerations: > > The main problem to be addressed is not a set of 'blessed' libraries > by Lua Team, but instead one repository of codes that the COMMUNITY > TRUST, USE, IMPROVE and HELP to increase. It means, when someone on > this list asks about a library, everybody must agree on a first > default answer. Public libraries are blessed by the community, not a > specific restricted set of people. > > Reasoning. Lua community, at least on this list, is obviously well > versed in programming/IT/CS which naturally leads to "I can write my > 'best' library myself that do what I want in my way", and that's > exactly the main problem. We can do it, but public libraries are > useful exactly for ones that can't or don't want to write their own > 'best' whatever. The ego of 'I can do it better' must be superimposed > by 'it is enough for most of them'. "THEM", not "me". > > Then, I propose the following project: > > LuaDEAL - Lua DEad Alive Libraries > Lua Modules > > They're not aimed to be "the best," most powerful codes, but something > useful enough for someone doesn't need to reimplement the wheel again. > They must have a well defined and stable "Lua-ish" API. Documentation > is mandatory. > > A) Composed mainly of categories: > Tomb1 - Lua-only libraries and codes > Tomb2 - Wrapper from well-established C libraries. > Tomb3 - Lua-only C libraries > > B) The design must follow the philosophy of minimalist, modular software: > 0) Open, community-based, development. MIT license whenever possible. > 1) Lua's "mechanisms instead of policies," whenever possible. > 2) They must do only one thing and do it well. The aim is to do a > trivial job. > 3) They must be as independent as possible but work very well together. > If you are wondering about examples, think about Lua itself and its > standard library as well as lhf libraries. > > C) Code Standards > 1) Follow semantic versioning. > 2) No use of globals, never, anywhere. > 3) Standard headers for different modules. > 3.1) Name of the module > 3.2) Date of module creation > 3.3) Author of the module > 3.4) Modification history > 3.5) Synopsis of the module about what the module does > 3.6) Different functions supported in the module along with their > input-output parameters > 4) Exported API must follow the existing Lua names and design > conventions. > 5) Must work flawlessly on recent versions of Linux/Mac/Windows if > the underlying necessary libraries are present. > > If only a subset of the readers of the list really commits to public > libraries, it means, codes for other ones use, I'm sure that a set of > standard modules could be available for the community still this year. > It obviously will require the rework os many wheels, fortunately to > they R.I.P. on the repository for a long time. Public libraries are an > exercise of detachment. > > Best, > Rodrigo > >
Attachment:
signature.asc
Description: OpenPGP digital signature