[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Lua distros again
- From: Dibyendu Majumdar <mobile@...>
- Date: Tue, 13 Feb 2018 14:43:34 +0000
On 13 February 2018 at 10:46, Lorenzo Donati <lorenzodonatibz@tiscali.it> wrote:
> Sadly I think this is a direct consequence of Lua team not wanting to
> endorse any specific initiative.
>
> I understand their decision of not wanting to create and maintain a "PUC
> standard" library collection, and I also understand their attitude toward
> backwards compatibility. That's ok. It's Lua team's way.
>
> But there is a big "but": not endorsing, say, a charter of committed people
> that took responsibility for creating a basic set of standard library was
> and is a big mistake for the future of Lua, IMO.
>
Hi, I think this depends on what you see as the future of Lua. I
cannot speak for the Lua team, but my impression is that they are not
looking to win the popularity game. Their intention appears to be to
create a minimal language / library that is still a powerful language.
The niche of Lua is that it comes with no baggage, and is therefore
eminently suitable for embedding as a scripting language in a larger
C/C++ application (I chose those languages as host languages as
embedding Lua in say Java or C# appears pointless).
I think Lua is still the strongest language in this niche.
> Even when thinking about embedding a language in an application, where Lua
> should be first choice, I hear people talking about Python and using Python
> (urgh!)! Sometimes because they don't even know Lua, and sometimes because
> they need better supported libraries, so they rule-out Lua!
>
In some domains where Python is already strong, there is an obvious
logic to using Python. For instance in the financial sector Python is
now becoming popular; I chose Lua as the scripting language in this
domain, but the response from users is 'why?'. My convenience (as
developer) in using Lua is immaterial, as you have to think of what
your users want.
Availability of an extended standard library would make Lua more
friendly to larger range of users. But keeping with Lua's spirit it
needs to be done outside of Lua as an add-on - and this is where the
problem lies, as without a clear leading solution, there are many
competing solutions with different objectives (I am adding my own to
the mix too!).
Regards
Dibyendu