 |
lua-l archive |
|
|
||
|
On Tue, Mar 13, 2018 at 01:43 Dirk Laurie <dirk.laurie@gmail.com> wrote:2018-03-13 1:25 GMT+02:00 Russell Haley <russ.haley@gmail.com>:
> I was merely imply that you and Dirk seem to have strong opinions on how to
> develop a standard Lua library and arguably have the credentials to do so. I
> think your post supports that thought.
Of course [1] we have strong opinions. They're the only kind of
opinion worth the name.
But actually I don't have any opinion at all on how to develop a
standard [extended] Lua library, I only have a strong opinion on what
it should look like. The typical module in it. I have no opinion on
how to achieve it.
Actually I can boil that opinion down to one sentence.
It should look as if the Lua team themselves designed it.
Not even Roberto's and Luiz's own modules pass that test. LPeg is
fiendishly clever and exploits Lua's abilities to the full, but it
never feels as if you are using Lua — you are using LPeg. Luiz's
modules are Lua taken to the extreme: not just "less is more", but
"least is most", including the documentation.
The stuff that actually reaches Lua has been very carefully brought in
from those esoteric extremes to what the ordinary person can cope
with. There are tradeoffs, and most important, implementation details
are kept out of the manual.
Study Lua's io and os libraries. Scrutinize the new library functions
brought in at 5.3. Do likewise.
[1] Your comparison with Hubert J Farnsworth is apt.
[2] These are the ones where Lua is pushing right against the
constraints [3] imposed by adherence to standard C.
[3] Occasionally breaking out of them: "only available on some
platforms". The envisaged extended library will have to do that too.
Whoah... we’e already talking about batteries again? I think the last thread was only fall of ‘17! The conversation train is getting tighter. (Integer indexes will be next, I believe?)There is a group that has been doing some work on this, but my observation is that none of them are especially focused on pushing this out, although they have done some very nice work.There are some very fine starting points already. I like Luvit. I like LuaRocks. I like (and donated to) LuaDist. There are others I’ve seen and like.One challenge is that batteries for Lua doesn’t fix any problems for the core use case that Lua was designed for (and hurts in many cases), except at the point of making a decision about which language a developer’s end users are likely to be familiar with. That is not a technical problem, but it is a significant problem, none the less.I’m most familiar with the television / media broadcast, digital signage and AV integration industries. All that Lua is perfectly suited to dominate. Instead, I see Python and sometimes _javascript_.Example: I’m close with one manufacturer that decided to go without scripting in their streaming appliances because they were sure they couldn’t afford the 2-3 megs they would need on their microcontroller platform. I told them about Lua and they said, “I’ve never heard of it.” I shared with them how it was used in games and how small it is and I sent them links, etc. Next time I saw them, they figured out how to add _javascript_.EVS, Ross, Scala, etc.: Python and _javascript_. Their attitude is that you can find someone that “knows Python” and it’s easy enough to integrate. Nobody expects it to be possible to do real time, every-frame scripting, so these languages are fine. Their imagination doesn’t include scripting at the level that Lua provides. For real time needs, they have C# and Java APIs.It is painful to watch this market default to what is popular and ignore the simple and elegant solution that is Lua. What could change that? Two ideas:1: An evangelist with resources to travel and give talks, similar to Roberto’s talks, but at industry conventions (NAB and InfoCom/AVIXA in my world).2: An organization that controls a Lua ecosystem/distribution. Not blessed by Lua’s developers. Has a governing body. Is funded in some small way. Oversees the high quality development of critical modules (sockets, concurrency, crypto, http, etc.). Makes standards for documentation, building, versioning, whatever else Dirk thinks is needed. ;)Who has the passion to get this done? Who wants to say, “I’m probably not the smartest most capable person to do this, but maybe this is what life has asked of me now...”-Andrew