On 31/12/2019 20:29, Steve Litt wrote:
> On Thu, 19 Dec 2019 12:14:12 +0100
> Italo Maia <italo.maia@gmail.com> wrote:
>
>> Javis:
>> https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/lua-python3.html
>> Other benchmarks have similar results. Memory consumption might also
>> be an issue.
>>
>> Personally, the batteries are not very important if the common
>> libraries one might need are easy to find/pick.
>
> I think you put your finger on the issue, Italo. One needs to:
>
> 1) Find the library
> 2) Pick the library
> 3) Install the library
>
> #2 involves, for each candidate library for a given task:
> a) install the library
> b) learn the library
> c) experiment with the library
> d) unless the library turns out to be the best:
> Discard all that effort
>
> #3 requires either my distro package the library, or I use luarocks,
> which I don't normally like to do (no more than I like Ruby gems,
> Python pip or Perl CPAN). Worse yet, #3 requires me to explain, to
> prospective users of my programs using the library, how to install the
> dependency on *their* computer, and a lot of times because dependencies
> have dependencies, that doesn't work.
>
> Contrast this to Python, which has a curated set of complete, tested
> and documented standard libraries, effectively meaning that almost any
> project you start in Python can be finished in Python using just the
> standard library.
>
> Of course, in the case of Lua the standard library must be in a
> different package to Lua itself, to facilitate tiny embedded programs.
> This doesn't mean Lua can't have a curated standard library, separately
> installed, and hopefully packaged by the distros.
>
> Lua is by far the best *language* I've ever used. However, due to lack
> of a curated and up-to-date standard library, it's not the most likely
> to produce a successful result in a computer application as opposed to
> an embedded program.
>
> A good starting point would be an official list of approved Lua
> libraries, with a search function, that tells the strengths of each
> library. That would be a great improvement over having to ask online
> and getting lots of opinions.
>
You really hit the spot!
> Thanks,
>
> SteveT
>
> Steve Litt
> December 2019 featured book: Rapid Learning for the 21st Century
> http://www.troubleshooters.com/rl21
>
>
On a related note, many years ago I read something about the success of
C (I can't recall exactly where or who wrote it, but it wasn't a
uninfluential author, IIRC).
That author stated that the success of C, despite being an inferior
language than Pascal, from an elegance and many other POVs, was that it
had a well defined machine model with a practical vision.
In particular: the core language modeled an abstract machine which was
sufficiently adaptable to any known architecture (Von Neumann based,
especially). But this was not the whole point: the core language would
have sucked without the presence of a well defined, and /separated/
/standard/ library that modeled what a high level user would expect from
a real system.
Pascal, OTOH, had integrated basic I/O in the core language (which
hampered adaptation) and left libraries to implementors (e.g. Turbo
Pascal was great, but it was Borland's vision).
The fact that the C library was standard and practical, made people
invest more effort in using C even for non-bare metal applications,
where it had no real edge over Pascal.
I think that the whole thing can be applied to Lua vs. Python. Lua as an
embeddable language is no match for Python, but sadly Python is often
chosen as an embedded language because:
- (a) It has a huge and stable standard library.
- (b) It has a huge user base which has gained because of (a).
- (c) It appeals to non-programmers which need to program something
wasting no time, especially because of (a) and also due to hype because
of (b).
- (d) Lua is not as widely known as Python nowadays, which depends on
(a), (b) and (c).
Note the "recursive/self sustaining" pattern in those reasons!
About (c) above: I've never been asked what is Lua by non-programmer
colleagues and students, unless I cited it first. OTOH I've been
frequently asked about Python!
We developers can appreciate elegance and minimalism and use Lua just
for that, but sometimes you have to solve problems and you don't have
time to roll your own solution.
A personal example of about a year ago: I had to write a script to
control an electronic instrument with a Windows PC via virtual USART
(serial port) over USB. The first problem was that every Lua library I
downloaded didn't work out of the box. Some were not maintained, others
were too difficult to install or didn't compile with my tools. I had no
time and I just wanted a small application with few files and no
dependency and no installation procedure.
NLuaSerialConsole is a generic Serial Port tool to take advantage of Lua's powerful binary string manipulation in what I would consider the proper context: Embedded in a language with a complete library and multi threaded capabilities. The serial interface is provided via DotNet. The full DotNet library is available within Lua scripts via NLua. NLua is *very* slick and embeds a full version of Lua so all your C modules are available too.
I'm eventually planning on porting to DotNet Core for full cross platform functionality.
All contributions/comments/wtfs welcome.
Russ
So I got my hand dirty, learned the intricacies of USART API in Windows
(the difficult part) and then rolled my own C library using Lua C-API.
It was dirty and not a very elegant solution, but it worked fine. OK,
kudos to Lua being so easy to extend but:
1. I had to be a barely decent C programmer (not easy).
2. I had to know Lua C API (easy).
3. I had to delve into the intricacies of Win32 C USART API (very
difficult).
All this took time I barely had, but I bit the bullet because:
1. I have a solution that works in Lua (even if brittle) written by me
so I know where to put my hands when something goes wrong, instead of
relying on someone on the Internet solving a bug on their barely
maintained library in a timely fashion for me.
2. I don't have another dependency which then I would have to maintain.
3. It is lightweight.
But, really, if I just had more expertise in Python, in that
circumstances probably I would have just used a Python script and be
done with it.
And if I didn't already know Lua, I will probably learn Python just
because of the hype (not good, but that's the crude reality) and because
it has every kind of battery included (very good!).
And if I were a non-programmer, no way I'd even think to use Lua (even
if I knew it existed). Just learn Python at the bare level needed to use
one of its /standard/ libraries.
Even if Lua is gaining users (I don't know, is someone aware of some
current numbers and trends) it is gaining much less users than Python,
of that I'm sure.
And Lua is actively scaring away non-programmers, IMO. Unless one wants
to buy the excellent books by Roberto, the only direct and free resource
to learn Lua is the reference manual (besides the ancient online PiL
that covers Lua 5.0). Which by itself is a bit hard on non-programmers
(Lua 5.1 one was a bit more easy reading, IMO).
The non-programmer is scared away just when it comes down to read some
of the standard library documentation. An example? Just out of the
os.date refman entry:
"If format is not "*t", then date returns the date as a string,
formatted according to the same rules as the ISO C function strftime."
Imagine a non-programmer professional (a physicist, a chemist, a
teacher?) reading that. "Just to format a date I must know C ?!?"
Yes, if you are a programmer you could understand that you only need the
strftime docs. And if you are also a C programmer you could understand
it is not so scary/difficult to retrieve that docs (cppreference.com
anyone?). But those are two BIG ifs.
And references to C are scattered throughout the entire refman, even in
non C-API parts!
But, as usual, I'm beating a dead horse. Until Lua Team decide they want
really to appeal to the wider non-professional "programmer" community,
there is no way to improve the situation, IMO. Lua will remain a
wonderful language with a fairly restrict niche user base, with everyone
reinventing their own wheels.
Yes, lua-l is friendly, but that's no substitute for a real free
comprehensive /standard/ library with good documentation.
Individual initiatives are usually doomed from the start without
endorsement from the "official" source (and whoever has been following
this list for some years, has seen many attempts to create
distros/standard libraries/active wiki sites go sour). Some are still
alive, but not kicking. Some are abandonware/completely dead.
Cheers!
-- Lorenzo
