Re: Breakthrough dream

[Frank Kastenholz <fkastenholz@...>]

On 3/25/17 3:54 PM, Egor Skriptunoff wrote:
> On Sat, Mar 25, 2017 at 10:26 PM, Dirk Laurie wrote:
>
>     2017-03-25 15:04 GMT+02:00 Rodrigo Azevedo:
>
>     > 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)?
>
>     This does sound a bit like someone who wishes to enlarge the listening
>     public of a radio station that broadcasts classical music, and comes
>     with suggestions like:
>
>     * breezy disc jockeys
>     * short, snappy pieces instead of those interminable symphonies
>     * phone-in discussion programmes
>     * jazz is fine music too, isn't it?
>
>
> The analogy with classical music is very incorrect.
> All 5 characteristics being discussed here wouldbe useful for all Lua users.
> They are not contradictory to set of features we already have in the
> language.


These particular changes _could_ be problematic.  The project I was on
developed an application environment, with apps coded in Lua, that runs
on a variety of platforms -- different processors and operating systems
and varying levels of resources.  On some systems we had 250MHz
cpu speeds, <10MB RAM for our part of the system, and the OS was not
Windows or a flavor of Unix.  Anything that would expand the footprint
of the core PUC-Rio Lua (larger libraries, type checking in the
compiler, etc) would be a problem. Similarly, anything that ties Lua
to a specific OS (or family) would be very bad.

That said,

1) What would be reasonable would be to make these sorts of
   features truly optional, selectable by #defines in something
   like "lua_features.h".  I would not want to have to go through
   all the source code unwinding things to pull out some features.

2) Despite what this list would like, Lua will never replace, or even
   come close to equating, Python or sh or ... as scripting languages.
   The others are too embedded in the world's mindset.  Lua's
   real strength is that it can easily be installed in some other
   program, giving that program scripting/config/etc-ability. That is
   its market niche. I would _strongly_ urge that the PUC-Rio folks
   never risk losing that niche as the consider new functions/features
   to add.

Frank Kastenholz