Re: Breakthrough dream

[Andrew Starks <andrew@...>]

On Sat, Mar 25, 2017 at 8:04 AM, Rodrigo Azevedo <rodrigoams@gmail.com> wrote:
> Based on the thread 'Selenophobia', and your major experience, choose 5
> characteristics you think indispensable to keep Lua advancing as a
> "general-purpose script language";
>
> 1) an expanded basic library (some batteries), well organized, maintained
> and documented. "Pure Lua" libraries at least.
> 2) easy installation on major operating systems (with shared libraries)
> 3) threads (pthreads!? not Lua's coroutine)
> 4) optional type annotations (performance, error check etc)
> 5) easy, transparent, way to port libraries to new versions of Lua.
>
> Is this possible to start, organize and support for a long period ( a
> 'larger' community)?
>
> Or Lua's community is so specialized, and happy, like the 'webdevs' of
> stackoverflow, that this is not possible in a foreseen future?
>
> and consequently the 'general-purpose script language' is an utopic,
> romantic, dream.
>
>
> --
> Rodrigo Azevedo Moreira da Silva

Taking the informal pulse of this list as presented to me by my own
memory, I would write this list in this way...

# Sandboxing is hard.

Whenever someone talks about sandboxing, this is the response that
they get. Lua is already constructed in a way that aides sandboxing.
Could more be done?

# Concurrency, especially between Lua States?

Again, Lua is fantastic for concurrency. Also, Lua is designed to
seamlessly integrate into any system environment, which means that any
deep-level concurrency support would be counterproductive to many
applications for Lua.

However, could more be done to speed up or aide in the marshaling of
native Lua values between threads? Specifically interned strings and
table structures? Maybe work on the new garbage collector might
provide an opportunity for some new mechanism.

# Lua as a general language? / How can Lua be more popular?

This issue is raised over and over again and probably will be forever,
until two things happen:

1. A new problem is solved by a new development / runtime environment.
2. That project uses a custom flavor of Lua and a set of well
documented, beautifully engineered libraries that enforce well
considered design limitations/opinions, while still respecting Lua's
unique style.

Until a compelling problem is solved with Lua (or Lua-esque) in that
space and in a way that makes people stop and try it out, there will
be no traction, even if Team Lua adds a bunch of standard libraries,
switches to 0 based arrays and adds ++ and -- operators. Since Lua's
primary use case is as a C library for embedding into system
languages, I believe that the most likely path is for someone else to
extend Lua and create a separate ecosystem with enforced design rules
for OOP, functional programming, etc.

Something like Luvit + Moonscript + killer app... or something.

-- 
Andrew Starks