 |
lua-l archive |
|
|
||
|
On 03/02/2020 03:02, Andrew Starks wrote:
On Feb 2, 2020, at 04:43, Lorenzo Donati <lorenzodonatibz@tiscali.it> wrote: 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.What if an organization, such as the Linux Foundation, would agree to host such an organization? Perhaps they would agree to help With marketing, trade shows, other exposure, provide a governance framework, etc.? Assuming they would do it with the blessings of PUC/Rio, do you think something like that would help? -Andrew
It's not a bad idea, in principle. I see just some practical obstacles:1. As you point out, would Lua team endorse such an effort? I strongly believe that with no such endorsement any initiative is doomed to fail.
That's a big prerequisite.2. It should take care also of the Windows "part" of the job, which is not obvious it would happen. And I think Lua shouldn't become a "*NIX"-only thing, also because most non professional devs are probably Windows users (and that's a big market share). Would the Linux foundation care to support Windows in a neutral and on-par way, without trying to win users for Linux or biasing its efforts toward Linux Lua distros?
3. Still we would need guidance and policies to define guidelines for the whole library. Just start coding and trying to come up with an API wouldn't work, IMO. We already have some libraries. We should strive for a consensus about:
A. What common problems the /standard/ library should tackle.B. What the structure of "The Library" should be (modules naming conventions, namespacing, disk layout, how to cope with new modules, etc.). How a single module should be organized to support backward/forward compatibility?
C. What "look and feel" should "The Libray" have? what style the APIs (plural!) should have (having a uniform API style across modules helps a lot in usability and documentation)? What error reporting style would it use? Are debugging facility for the library be consistent across modules? Should we have a "framework" for error reporting/unit testing/ debugging (also usable by client code), or do we need to use a simpler set of very basic facilities (small modules, no framework-like) that every module writer should use to integrate it in the library.
D. How would a module be accepted in the library; how to accomodate developers with few time to spend on maintenance (copyright should be transferred to the "foundation"? The "foundation" should allocate dev resources?). Maybe some devs wants to contribute with few hours a month, are there modules where many devs can work only for limited time? Maybe use their time to build unit tests?
Someone has to decide all this.I repeat "LOT of policy" if we want to avoid past mistakes and really want to build a solid, stable, backward/forward compatible and future-proof code base, to which big and small contributions can be integrated in a harmonic way. More so, if we want the library to be more Lua-like than Python-like.
A good "Standard Library" is not (should not?) be just an enormous collection of sticked together code.
I'm not saying it's easy, on the contrary, we failed many times because it is not easy at all. Good management is all but easy (and few developers, in my experience, are also good managers)!
Disclaimer: I'm not at all a manager type (/defintely/ not), but I can recognize a good manager when I get to know one.
-- Lorenzo