Re: LuaDEAL - Lua DEad Alive Libraries

[Dennis Fischer <darkwiiplayer@...>]

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