Re: [mildly OT] Some info about Python

[Sean Conner <sean@...>]

It was thus said that the Great Lorenzo Donati once stated:
> On 03/02/2020 03:02, Andrew Starks wrote:
> >
> >>On Feb 2, 2020, at 04:43, Lorenzo Donati
> >>
> >>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?
> 
> 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?

  And that's a problem because Windows doesn't come with a development
system by default.  And from what I understand listening to complaints about
Windows on this list over the years, if you use one tool chain, you often
can't mix artifacts from another tool chain.

  I mean, if it were up to me, I'd say "screw Windows!" but I know that is a
very unpopluar opinion 8-)

> 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.

  There was a list Dibyendu gave a two years ago [1]:

	- lpeg
	- luafilesystem
	- luasocket
	- libuv (Luvit)
	- libcurl (wrapper tbc)
	- lua-cjson
	- torch7
	- luaossl
	- cephes (wrapper tbc)
	- luaffifb (port of LuaJIT FFI interface)

  Some, I agree with, some I don't.  But that list is a start.

  But the bigger issue is the overlap and difficult composability (or
interoperability) of modules.  This stems from two issues---a module covers
too much territory, and the non-Luaish nature of most modules.  I've
commented before on non-Luaish modules [2].  I have always contended that
C-based modules should be more Luaish, but most people are lazy, do the the
simplist thing (wrap a C-API in a Lua API that mimics the C-API) and never
bother to make a higher level Lua API (if that makes any sense).

> 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?

  Again, that's hard and my own solutions isn't popular (nor well understood
by some people).  And even with my own solution, I have made some blunders. 
Naming is one of the three most difficult things in computer science (the
other being cache invalidation and off-by-one errors).

> 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? 

  I've been working on a standard library, and for error reporting, I've
been using the method used by the io library:

	thing[,errs,erri] = functioncall()

where 'thing' is either the object, or nil, and when it's nil, the other two
values are an error string and error number.  I'm not happy with the
returning of the error string, but I can see why Roberto went with that
approach.  I personally prefer the error number, but ANSI C only defines
three values:

	EDOM
	ERANGE
	EILSEQ	-- C99

  I'm not a fan of error() in general (or exceptions) but I will agree that
they can be useful in some cases.  

> 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.

  I'm more in favor of library approaches over frameworks, but it's becoming
clear to me that *some* framework for network (or advanced file I/O) is
probably required.  I prefer modules that have a definite focus on one type
of problem, say directory manipulation, rather than a "kitchen-sink"
approach.

> 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.

  -spc (Not much to add ... )

[1]	http://lua-users.org/lists/lua-l/2018-01/msg00513.html

[2]	Some examples:
	http://lua-users.org/lists/lua-l/2013-11/msg00400.html
	http://lua-users.org/lists/lua-l/2015-03/msg00001.html