Re: Dead Batteries

[Steve Litt <slitt@...>]

On Sat, 11 Jan 2020 01:42:57 +0000
Dibyendu Majumdar <mobile@majumdar.org.uk> wrote:

> On Thu, 9 Jan 2020 at 20:44, Steve Litt <slitt@troubleshooters.com>
> wrote:
> >
> > On Sun, 5 Jan 2020 22:00:15 +0000
> > Dibyendu Majumdar <mobile@majumdar.org.uk> wrote:

> > > Well Python is arguably a better general purpose language  
> >
> > Only because batteries.
> >  
> 
> Not only because of. In my experience Python is a more user friendly
> language. Lua is more geek friendly.

The "Python is more user friendly" might have some merit, but the
question is which is a "better general purpose language". Any user
friendliness criteria are dwarfed by the fact that Lua's syntax is
simple and it has only two types of complex data: Table and Metatable.
IMHO Lua, *as a language*, is both more powerful and easier to
understand.

> 
> >  
> > > and has a
> > > very powerful set of libraries. Why does the world need another
> > > one?  
> >
> > Personally speaking, so I can have a batteries included language
> > whose only complex datatypes are table and metatable.
> >
> > As far as the question "why does the world need another one?", one
> > could have asked that about C, because you can do *anything* with
> > C. It might take ten times more code, it might tremendously
> > increase the likelihood of errant pointers and buffer overruns, but
> > C is the ultimate general purpose language: Why do we need another
> > one? 
> 
> Of course a new language is always possible, but in general, languages
> fit into specific niches. Lua is successful because it fits into its
> own niche. It cannot and should not be a Python replacement.

You can repeat your assertion a hundred times, but it's still just your
opinion. If Python and Lua had equally capable and reliable "batteries",
I'm pretty sure that Lua would be more productive not only in the
embedded arena, but in office automation, data processing, conversions,
and web apps.

> 
> > Just as a point of information, I recommended a curated group of
> > add-ons be in a separate package, not in the Lua package. That way
> > embedded programmers can use just Lua.
> >  
> 
> I think Lua team have endorsed LuaRocks - that is as far as it will
> ever go probably.

Luarocks is a package manager, not a group of applications.

> To do anything better is significantly more difficult

Yes it is.

> and requires a
> huge amount of effort. 

Yes it does.

But given the fact that Lua, as it has existed for the past five years,
is a pretty much perfect language, curating a group of approved add-ons
would be the best way to improve Lua.

SteveT

Steve Litt 
January 2020 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust