 |
lua-l archive |
|
|
||
|
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.
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