[mildly OT] Some info about Python

classic Classic list List threaded Threaded
121 messages Options
12345 ... 7
Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Peter Hickman-3
On Sat, 18 Jan 2020 at 17:21, Steve Litt <[hidden email]> wrote:
IMHO in this day and age, you need a language that can easily and
reliably and without experimentation interact with XML, HTML(5), Xhtml,
databases, JSON, YAML, DOM, sockets, IPC, complex numbers, and probably
twenty other things I haven't thought of yet. And with small appliance
devices doing ever more mainstream things, some of these batteries will
probably become more important, in embedded programming, in the future.

This is both a blessing and a curse. Having them available is one thing, having them as part of the language is not. My favoured language is Ruby, I can do quite a lot with just the core language before having to reach for a library, usually for JSON, XML or database access. Lua however has me reaching for a library (in the loosest sense) for things that are part of the core language in Ruby. Ruby is convenient when knocking out code but it comes with both a performance hit and massive memory footprint. That is a tradeoff I understand and can live with

With Lua I have amassed a small library just to do the sort of things that are a given in languages like Ruby and Python even before you consider things such as JSON, XML and databases. Which slows me down as I constantly have to find which library to pull in. For this I get better performance (I have converted applications from Ruby to Lua for the performance boost) and a much smaller memory footprint. Again a tradeoff I understand and can live with

I use Lua and Ruby (and C) not because they are the same but because they are different. I no longer program in Perl as it does nothing that Ruby can't. I only use Python when some esoteric module is needed or I am dealing with 3rd party code. But when I want to try something out Lua is a good choice unless I envision serious string mangling or that something OOP may be the best solution

Lua is a simple and powerful language. Think JSON vs XML. JSON is in many ways a deficient standard compared to XML but amazingly useful. XML allows much more control and reduces ambiguity but at a cost

JSON wouldn't become better if it got 'feature envy' for XML. Lua will never be a better Python than Python, and will probably be worse for trying
 
So, in my opinion, Lua would greatly benefit from an official, blessed,
curation of libraries available both in a single package for when disk
space isn't at a premium, and a-la-carte for embedded.

Although I get pissed when searching for an existing Lua library to do some task to find either zero or six. Not having standard libraries is not necessarily a bad thing. In other languages the standard / default library for something tends to have a kitchen sink set of features just in case someone might need feature X. This comes at a cost, the codebase is larger, it has codepaths that are addressing features you have no interest in, hitting performance and eating memory. More code means more possible bugs. Just look at the standard Python logger. It is truly a marvel of engineering. Of which I use at most 10% but the remaining 90% is baggage my application must carry. Same with Ruby, every unused language feature is hitting performance and eating memory

I found four logger libraries for Lua but ended up writing my own (so now we have five). The evaluation and eventual development of my own solution slowed down development (with Ruby or Python there is no real choice, just read the docs and write code) but I have a solution that does exactly what I want. It does it as fast as possible. It uses the least memory possible and being small (54 lines including comments) it is not going to be difficult to hunt down any bugs. The very reasons I selected Lua for that project, these are Lua's strengths

To compete with Python or Ruby or any other general purpose language Lua needs to be clearly better than them otherwise there would be no good reason to switch. I left Perl for Ruby because I was doing a lot of OOP and Ruby did that sooooooo much better. If Lua started to get more like Ruby and less like the current Lua I would probably ditch Lua. Why use an inferior clone of Ruby when you can use Ruby?

I use a set of languages not because they are the same but because they are different. Each language and their ecosystem has different strengths and weaknesses and so are better fitted to solve particular problems. Convergence is not a good thing in this case, not just the language but the ecosystem too

Sorry for the ranting, it is probably not as coherent as I hoped

Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Sean Conner
In reply to this post by Lorenzo Donati-3
It was thus said that the Great Lorenzo Donati once stated:
> On 17/01/2020 09:03, Marc Balmer wrote:
>
> >I usually pick my tools to fit the work at hand, not by means of what
> >is currently en vogue...

  So does that mean you use Fortran for numerical analysis, COBOL for your
business logic, Perl for text munging and Intercal for job security?  What
exactly does it mean to pick the tool (programming language or tech) for the
work at hand?  In my own cynical way, I tend to think it's said more by tool
mavens with a preference towards hipster views followed by what is popular.

> Exactly!
>
> And what I reported seemed to indicate that a great majority in the
> world find Python more apt at solving their problems than Lua.
>
> Unless you think all those Python programmers/users are funny people
> that choose a language using the criteria they would when choosing a
> fancy new scarf.

  Yes, pretty much.  It's popular, so I must learn it.  Who uses Lua?  Why
bother with Lua when that limits my job prospects.

  On the other hand, going with Python (or any other hip new popular
language like Go) you are now competing against scores of other programmers
who know just as much as you do.  The Lua jobs might be few and far between,
but I stand a better chance of landing them that a Python programmer.

  But who thinks like that?

> Ask yourself: would you (a company) prefer a Python solution that is
> bloated and slow, but still "fast enough", well supported (because
> "everyone" know Python) and that is created in 10 days, or an equivalent
> Lua solution that takes 2 month to be created and that cannot be
> supported long term because you don't even know where to find an
> alternative Lua dev in your area would the need arise? Not to mention
> the level of support of libraries.

  It's funny you mention that.  I used Lua for a few projects at work (one
is very imporant (such that it's the front end to the actual product that
generates *all* our profit at the company) and yet, I'm only one of two
programmers there that know Lua.  Our QA engineer keeps using Python for
running tests because he finds it easier to use than Lua (despite the fact
that most of our testing tools I've written were in Lua when I was in the QA
department).

  Changes to my part of the codebase usually take on the order of hours, not
days or even a few weeks like some other parts (written in C and C++).  I
mainly attribute that to Lua's coroutines, since the main logic of the
program (which is event driven using select() [2]) looks more like
imperative code than chopped up callback hell or asynchronous promises or
whatever the new hotness is in nodejs these days.

  Also, back in late 2018, a new project was announced.  I (by myself, on my
own) managed to write 90% of the code base in Lua in two days (the last bit
wasn't done because of some still open questions).  The other team that
actually started writing the code took the better part of a year (I
think---I'm not entirely sure they're done yet) to write the program.  But
hey, I program in Lua, what so I know?

> Again, Lua is better at some things, but that doesn't make it a "good"
> general purpose PL (and being Turing complete doesn't count in practice)
> if people don't /use/ it as a GP-PL.
>
> And, btw, this huge user base means that Python use is growing even in
> areas where Lua definitely shine: embedding. I find more and more
> projects that use Python as embedded language. I can't say how difficult
> is to embed Python, but I'm sure that if the demand grows, someone in
> the Python community will find a way to make it simpler.

  And here I thought that Python was shedding users to Go, because of
similar easy of use plus it runs faster (and is just as opinionated, if more
so, than Python).

> I really think Lua Team should reconsider some of their positions on the
> development model of Lua, otherwise they risk a slow descent into
> irrelevance in the PL landscape in a couple of years (except maybe some
> very limited niches).

  They might not even care.

  -spc (Never been one to use the popular stuff ... )

[1] https://blog.osteele.com/2004/11/ides

[2] Well, poll() actually on the production server, epoll() on Linux and
        kqueue() on Mac, but the later two are mostly test platforms.

Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Sean Conner
In reply to this post by Peter Hickman-3
It was thus said that the Great Peter Hickman once stated:
>
> But when I want to try something out Lua is a
> good choice unless I envision serious string mangling or that something OOP
> may be the best solution

  For serious string mangling I reach for LPEG.  Yes, it has a learning
curve, but it is well worth learning if you munge tons of strings.  I tend
to reach for it over Lua patterns.  

> Although I get pissed when searching for an existing Lua library to do some
> task to find either zero or six. Not having standard libraries is not
> necessarily a bad thing. In other languages the standard / default library
> for something tends to have a kitchen sink set of features just in case
> someone might need feature X. This comes at a cost, the codebase is larger,
> it has codepaths that are addressing features you have no interest in,
> hitting performance and eating memory. More code means more possible bugs.
> Just look at the standard Python logger. It is truly a marvel of
> engineering. Of which I use at most 10% but the remaining 90% is baggage my
> application must carry. Same with Ruby, every unused language feature is
> hitting performance and eating memory

  I use syslog() for my lgging needs (and yes, I did write my own wrapper
for that [1]) and I was curious as to what a "logging module" would do that
syslog() doesn't.  I took a look at Python's logger and OH MY GOD WHAT
DOESN'T IT DO?  I'll leave that mess up to the syslog daemon to handle [2].

> I found four logger libraries for Lua but ended up writing my own (so now
> we have five). The evaluation and eventual development of my own solution
> slowed down development (with Ruby or Python there is no real choice, just
> read the docs and write code) but I have a solution that does exactly what
> I want. It does it as fast as possible. It uses the least memory possible
> and being small (54 lines including comments) it is not going to be
> difficult to hunt down any bugs. The very reasons I selected Lua for that
> project, these are Lua's strengths

  I generally write my own library code.  lposix (or is it luaposix?  I
forget which one is the current standard) was just too large for my tastes,
with functionality overlapping that of luasocket.  luasocket doesn't have a
good design (in my opinion).  luafilesystem is too heavy to use (because of
portability issues) and the list goes on.  My approach was to have well
targetted libraries that work well together (and prevent unneccessary
overlap), and I have:

        org.conman.fsys - file system related calls
        org.conman.clock - get time, set time, sleep
        org.conman.process - process creation
        org.conman.signal - signal related functions
        org.conman.net - sockets and network addresses
        org.conman.tls - TLS wrapper based on LibreSSL
        org.conman.net.tcp - create file system like IO over TCP
        org.conman.net.tls - create file system like IO over TLS
        org.conman.nfl - network event driver framework
        org.conman.nfl.tcp - handle TCP connections per coroutine
        org.conman.nfl.tls - handle TLS connections per coroutine
        org.conman.pollset - select()/poll()/kqueue()/epoll()
        org.conman.syslog - wrapper for syslog
        org.conman.errno - list of system error values
        org.conman.env - load environment vars into table

  Theer are more, but I think you get the idea.  It took several years go
get this all written and designed, and I'm still mucking with them to this
day.  But now that I have them, it's easy to whip up stuff like a gopher
server [3] or a SIP processor (for work).

  Now that I think about it, I think this lack of modules designed to work
well together is possibly missing from Lua.

  -spc

[1] https://github.com/spc476/lua-conmanorg/blob/master/src/syslog.c

[2] Oh, and I wrote my own syslog daemon in Lua as well.

        https://github.com/spc476/syslogintr

[3] https://github.com/spc476/port70

Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Lorenzo Donati-3
In reply to this post by Steve Litt
On 18/01/2020 18:21, Steve Litt wrote:

> On Sat, 18 Jan 2020 16:05:29 +0100 Lorenzo Donati
> <[hidden email]> wrote:
>
>> On 17/01/2020 09:03, Marc Balmer wrote:
>>>
>>>
>>>> Am 15.01.2020 um 16:59 schrieb Lorenzo Donati
>>>> <[hidden email]>:
>>>>
>>>> Hi all!
>>>>
>>>> On a recent thread ("Dead Batteries" ) I argued that Lua lost
>>>> terrain over Python.
>>>>
>> [ snip]
>>
>>>
>>> I usually pick my tools to fit the work at hand, not by means of
>>> what is currently en vogue...
>>>
>>
>> Exactly!
>>
> [snip]
>
>> One could argue ad infinitum, but the hard data show that more and
>> more people find Python solves their problems "better" [1] than
>> Lua. And Lua is losing user base on a daily basis (at least in
>> relative numbers).
>>
>> [1] "better" meaning: more readily, more thoroughly, more rapidly,
>> more whatever. Heck! They might not even know Lua exists for what
>> matters.
>
> The preceding assertion, which I agree with in a limited context,
> is, in my opinion, the most important in this email. I'd like to
> paraphrase the preceding assertion as "If you start a project in
> Python, you're more likely to finish it in Python as opposed to if
> you'd started it in Lua and expect to finish it in Lua."
>
> More on that later...
>
>
> [snip several similar assertions and arguments]
>
>> Again, Lua is better at some things, but that doesn't make it a
>> "good" general purpose PL (and being Turing complete doesn't count
>> in practice) if people don't /use/ it as a GP-PL.
>
> [snip]
>
>> I really think Lua Team should reconsider some of their positions
>> on the development model of Lua, otherwise they risk a slow descent
>> into irrelevance in the PL landscape in a couple of years (except
>> maybe some very limited niches).
>
> This thread was spawned by the "Dead Batteries", but this particular
> post takes no position on "batteries" (a well curated standard Lua
> library). This email could be taken one of two ways:
>
> 1) Python's more likely to solve your problem because and only
> because Python has "batteries" and Lua doesn't, so Lua batteries are
> necessary and sufficient to make Lua preferable for most programming
> than Python, so Lua should acquire batteries.
>
> 2) Python's more likely to solve your problem because and only
> because Python has "batteries" and Lua doesn't, so because Python's
> more likely to solve your problem, Lua should confine itself to
> embedded, where Python just can't go, and not bother with batteries.
>
> In my opinion #2 is circular thinking non-logic.
>

Your #1 interpretation is what I definitely meant, but I /fear/ #2 will
be the reality in a couple of years, and many users in this list seems
to think so (sadly IMHO), i.e. they think Lua is good as is for them,
and don't want Lua to compete with other PL in one of its PITA area
(i.e. curated, /extended/, /supported/ and /standard/ library).



> By the way, it's not just Python. I've been studying Tcl for the
> last ten days. Tcl has "batteries" galore, they're in one standard
> library package that's separate from the Tcl package itself, and so
> far I've found they all work perfectly except for the Huddle object
> (serialization). Even though I just started Tcl, because of
> batteries, I'd be more confident of starting a difficult project in
> Tcl than in Lua.
>
> IMHO in this day and age, you need a language that can easily and
> reliably and without experimentation interact with XML, HTML(5),
> Xhtml, databases, JSON, YAML, DOM, sockets, IPC, complex numbers, and
> probably twenty other things I haven't thought of yet. And with small
> appliance devices doing ever more mainstream things, some of these
> batteries will probably become more important, in embedded
> programming, in the future.
>

I completely agree.


> So, in my opinion, Lua would greatly benefit from an official,
> blessed, curation of libraries available both in a single package for
> when disk space isn't at a premium, and a-la-carte for embedded.
>

Yep!

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

Cheers!

-- Lorenzo (beater of dead horses).

Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Αγαθοκλής
In reply to this post by Sean Conner
On Sat, Jan 18, at 08:36 Sean Conner wrote:
>
> > ... The evaluation and eventual development of my own solution
> > slowed down development (with Ruby or Python there is no real choice, just
> > read the docs and write code) but I have a solution that does exactly what
> > I want. It does it as fast as possible. It uses the least memory possible
> > and being small (54 lines including comments) it is not going to be
> > difficult to hunt down any bugs. The very reasons I selected Lua for that
> > project, these are Lua's strengths

>  ... My approach was to have well targetted libraries that work well together
>  (and prevent unneccessary overlap), and I have:

> org.conman.fsys - file system related calls
> org.conman.process - process creation
...

> Now that I think about it, I think this lack of modules designed to work
> well together is possibly missing from Lua.

This system which is based on directory hierarchy, combined with a kind of a lazy
evaluation - the interpreter knows about modules/functions, and evaluates code at
the first need - is perfectly aligned with the nature of Lua. The idea is to think
in terms of provided "functionality" which is expected to exist. As always is the
design that matters and provides the solution.  In this case the Lua Team doesn't
have to do almost nothing; perhaps just only the introduction of such a mechanism,
though quite possible not even that. Imagine a directory hierarchy, divided first
by Lua versions lying in your disposal, that you can then load a function by using
the mechanism and use it as it is, or just pick up a function in your code as a
basis to extend or reduce it to suit the specific needs. You can even put it in
a table and do all this crazy stuff, like real time coding and evaluation¹ for
self healing systems/purposes or whatever.

You have to forget though Python|* and comparisons with them. This is Lua. So
use with no mercy it's uncomparable strengths, which are out of competition.

¹ http://lua-users.org/lists/lua-l/2020-01/msg00132.html

Best,
  Αγαθοκλής

Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Dibyendu Majumdar
In reply to this post by Sean Conner
On Sun, 19 Jan 2020 at 01:37, Sean Conner <[hidden email]> wrote:

>   I generally write my own library code.  lposix (or is it luaposix?  I
> forget which one is the current standard) was just too large for my tastes,
> with functionality overlapping that of luasocket.  luasocket doesn't have a
> good design (in my opinion).  luafilesystem is too heavy to use (because of
> portability issues) and the list goes on.  My approach was to have well
> targetted libraries that work well together (and prevent unneccessary
> overlap), and I have:
>
>         org.conman.fsys         - file system related calls
>         org.conman.clock        - get time, set time, sleep
>         org.conman.process      - process creation
>         org.conman.signal       - signal related functions
>         org.conman.net          - sockets and network addresses
>         org.conman.tls          - TLS wrapper based on LibreSSL
>         org.conman.net.tcp      - create file system like IO over TCP
>         org.conman.net.tls      - create file system like IO over TLS
>         org.conman.nfl          - network event driver framework
>         org.conman.nfl.tcp      - handle TCP connections per coroutine
>         org.conman.nfl.tls      - handle TLS connections per coroutine
>         org.conman.pollset      - select()/poll()/kqueue()/epoll()
>         org.conman.syslog       - wrapper for syslog
>         org.conman.errno        - list of system error values
>         org.conman.env          - load environment vars into table
>
>   Theer are more, but I think you get the idea.  It took several years go
> get this all written and designed, and I'm still mucking with them to this
> day.

Nice. But I guess these are Linux only?

Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: was: Some info about Python: Back to batteries

Pierre Chapuis
In reply to this post by Steve Litt
> Here it is. We're asked "why should we enable Lua as a general purpose
> language?" Pierre used Lua's natural speed to make it a better CGI
> language than PP&R. Imagine how many more of us would do this if Lua
> had tested and curated packages for DOM, XML, and the like, so that you
> never have to spend time evaluating competing softwares, and whatever
> software you write is likely to have its dependencies available
> anywhere the Lua Standard Library exists.
>
> The existence of Python doesn't make Lua useless as a general purpose
> language.

Sadly, I have to admit something though: today if I have to choose a
backend stack for a serious Web project it will probably be Python-based,
and I use Ruby on Rails at my current job.

--
Pierre Chapuis

Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Eretnek Hippi Messiás
In reply to this post by Αγαθοκλής
hi there! :)

Αγαθοκλής, what do u mean by self-healing systems? sounds like fun, but i couldnt figure it out... so when something cant be tested before trying it out (like if having sufficient free resources in a multitasking environment), but its still handled, thats not a thing that i would call "self-healing", cuz the code that can handle a failure must already exists somewhere in that case. otherwise its either not _self_-healing or it would require a true ai that i believe is really far from our statistics based garbage-summarizator engines, that are called to be "ai"s :D (((that "dreams" about dogs with an eyeball in their assh*les @g**gle (deepdream), or the one that becomes a sexually open-minded nazi @m$ (tay), or the pair of ais that was advertised as they "invented" their own "language" @[ f], thats imho more like when u put the mic too near to the speakers and it generates a sharp noize :D ... and so on, but its better to stop here :D )))


> This system which is based on directory hierarchy, combined with a kind of a lazy evaluation - the interpreter knows about modules/functions, and evaluates code at the first need

i know u wrote this to Sean, but just for the record, my approach is to maintain a list of bidirectional dependencies, in a tree (that is just a special graph :D ) and then it wont be an overhead on every lookup with metamethod magic, and it can also be modified programmatically, so a great part of refactorization can be automatized... or better said, this has a different cost, i must localize the necessary nodes, but not their contents, cuz otherwise, i couldnt play live-patching games...

[not really important part]
btw recently (dec 6) i killed my hdd (rip) while having only outdated backups, where my app misses 3months (and the rest like 1.5yr (so therefore my new awesome protonmail for example :D )) so currently i dont have what im talking about, and i was even only really near to achieve this (ive slept with suicidal amounts of coffee during that missing time) but i still have like 90% of my missing codes in my head, and my actual goal was to reach a state where every single pixel will wait for me just like when i closed my app :D even my universal graph handler have lost a whole month, that already has 4months from my early development time of my app, thats actually the lion part of it... now it waits in that older state while im making an awesome new system with really much proper groundwork, cuz i had no time to make it happen before, cuz i wanted to be ready with my milestone in my app, lulz, and i will also make my backup semi-automated, just like how i wanted to do much earlier from my app... X'D hey kids, never forget to make some fresh backup! :D (<-reminder for myself)
[/not really important part]

bests! :)

Sent with ProtonMail Secure Email.

Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Sean Conner
In reply to this post by Dibyendu Majumdar
It was thus said that the Great Dibyendu Majumdar once stated:

> On Sun, 19 Jan 2020 at 01:37, Sean Conner <[hidden email]> wrote:
> >   I generally write my own library code.  lposix (or is it luaposix?  I
> > forget which one is the current standard) was just too large for my tastes,
> > with functionality overlapping that of luasocket.  luasocket doesn't have a
> > good design (in my opinion).  luafilesystem is too heavy to use (because of
> > portability issues) and the list goes on.  My approach was to have well
> > targetted libraries that work well together (and prevent unneccessary
> > overlap), and I have:
> >
> >         org.conman.fsys         - file system related calls
> >         org.conman.clock        - get time, set time, sleep
> >         org.conman.process      - process creation
> >         org.conman.signal       - signal related functions
> >         org.conman.net          - sockets and network addresses
> >         org.conman.tls          - TLS wrapper based on LibreSSL
> >         org.conman.net.tcp      - create file system like IO over TCP
> >         org.conman.net.tls      - create file system like IO over TLS
> >         org.conman.nfl          - network event driver framework
> >         org.conman.nfl.tcp      - handle TCP connections per coroutine
> >         org.conman.nfl.tls      - handle TLS connections per coroutine
> >         org.conman.pollset      - select()/poll()/kqueue()/epoll()
> >         org.conman.syslog       - wrapper for syslog
> >         org.conman.errno        - list of system error values
> >         org.conman.env          - load environment vars into table
> >
> >   Theer are more, but I think you get the idea.  It took several years go
> > get this all written and designed, and I'm still mucking with them to this
> > day.
>
> Nice. But I guess these are Linux only?

  Posix.  I use these under Linux, Mac OS-X and Solaris.  I don't use (or
have) a Windows system to test any of these on.

  -spc


Reply | Threaded
Open this post in threaded view
|

Re: was: Some info about Python: Back to batteries

Eretnek Hippi Messiás
In reply to this post by Pierre Chapuis
hi there! :)

really related, everyone must read it at least twice!!!!4
(a bunch of translation links are there, at the bottom of it, as its not an easy reading, and please add more translations to this gem to spread the word, in case if you are fluent in klingon, elf or whatever like so. thx! :) )

(i already dont strictly care about the title mess behind the main topic, but im still about the same... :D )

The existence of Python doesn't make Lua useless as a general purpose
language.
Sadly, I have to admit something though: today if I have to choose a
backend stack for a serious Web project it will probably be Python-based,
and I use Ruby on Rails at my current job.

thats just a personal choice, well, a popular one, especially in the business sector... ive selected github://kernelsauce/turbo to be my server engine, cuz it knows everything that would be a pita to make it all on my own, and theres the more serious openresty for the lazy ones who need something more, but i would go for less if it turns out that turbo isnt really good enough :D

actually, and in general, i hate bloatware cuz i dont wanna touch what i cant learn. otherwise, i would break something silently (or loudly) and shoot my leg. sure thing, there are some more rare components that are based on well defined purposes, that can be accepted even as-is, cuz they are stable, without significant garbage included, and with pretty, smart, tasty and sane codes behind them, like lua, luajit, curl, unicode, linux, libressl etc... in contrast with the things from the hype driven development bloatcollectors, where no1 knows what happens behind the scenes, and they arent really reliable... i also dont like language level package managers cuz of this, too many traps are included for a high cost. sure thing, i can do instant miracles, customers are happy, i got paid and run away before it start to burn in flames.... thats why i wanna break free from my web dev role... (nope, im not like those ppl, ive just described.)

just imagine a case when u wanna build something that lasts, and that can be relied, and where u can do whatever u want. that requires a different mindset than what we are currently oppositing lua with... nobody have time to keep away bitrot from things like fancy new n+1 web frameworks, they come and go, wordpress likes to catch on fire under every second constellation, and uve got no idea why it happens, cuz of those modules that are JustWorks™, cuz the wp must be updated against vulners and what not, but the modules are often developed on a hit n run manner, and im still not about the amount of those modules that ppl will use... (no, hopefully i didnt have to play much with wp and the like...)

but yea, tasty opensauce! u can do eeeeverything u can dream about! u only need to learn a dozen of languages, frameworks, read the commits, follow the mailing lists be on irc know how to divide with zero and ur there! ... ohh, theres the community! just send a ticket and profit! (spoiler: kinda often nobody cares https://www.monkeyuser.com/assets/images/2016/10-expectation-vs-reality-open-source.png ) i dont even really like to ask things on forums, either cuz its just a simple thing to save myself a few clicks when i see experts who could sacrifice a fraction of that time it will be to discover the rabbit's hole, when they already wasting their time there, and then i get rtfm&stfw, or when its about complicated stuffs, then tldr&silence comes in exchange for the time of telling possibly awesome basic ideas/methods/whatever...

so yep, making important things must be reliable, that requires ppl to be able to read and touch the code base that they use. its even better profitwise in the long run, and there are always enough project ideas out there in the wild to pick one thats not just a one shot project, but such as ppl can develop their customer circles around their own beloved code bases...

so back to my initial topic, a web server isnt that much of a big thing, compared to a freestanding gui that can make all of my dreams happen, and tekui is a thing that compares to nothing else out there (as far as i know right now), its just not overengineered, it can be read up to the last letter, it can serve all my basic needs out of the box, and it is flexible enough to make me able to implement such graphical things that doesnt exist in any general gui toolkits, without making my nose bleeding with its initial code base - even if it isnt 100% polished, and even if its nearly abandonware (maybe thats a good thing; otherwise its just considered to be basically feature-complete, and its main author is responsive, just busy in general). its a gui that can be touched, that doesnt really bleeding, that wont run away with its development governed by a huge community (that makes a bloatware) and its already really much powerful and flexible. i love it! :)

on pythonland, ive seen things like wx binding (it was 2.x only, when i already wanted stuffs from 3.x, it relies on an external lib, based on c++ thats just an another untouchable beast, its bloated, and what not, but i must note that i was nowhere to my current knowledge in those times, and it still cant draw a single pixel on a canvas, if im right :D ) and tkinter (that came from the book that ive initially used to learn python from) is a slow beast that supports 4 different programming languages that i dont care about (i wont learn all of them to be compatible and i wont clean it up and i dont wanna follow the crowd) and its written in some kinda klingon dialect (tcl)... the nearest to my needs were racket and io languages so far now, but neither those can really competite with my current funds... (im looking up everything i can find in the wild, as i dont wanna be on the wrong ship, cuz its hard to migrate, but ive spent here a few years now, and nothing could say that lua isnt what i was looking for or that there is anything that could really beat it...)

otherwise, the universal graph handler, that im talking about on a regular basis, would be kinda much painful with the fundamentally different dataset types in python, while the miracle behind it is that every data structure is a graph, so a graph handler can handle anything, and can be the connection between all the graphs, like currently its for matching lua tables with the filesystem, thats an awesome thing, it can be used for iterate, search, compare, repalce, dump, serialize, merge and what not anything that is based on graphs, that is actually any kinda data. even the ast is a graph. (no it doesnt know all of these right now, but these can be done without the need of refining this much different beasts when ive got an idea for one of them). the universal parser will be the next level of this, as that will make a graph (or any special case of it), as everything is just a bytestream on the disk. python would be a huge pita for such tasks, while it would also be really weak for it, c wouldnt be enough flexible, cuz its compiler based, and if there is something big to link against, then its also a slow task, so no live-coding is possible there, even if that isnt as much of a strict requirement... aaand, for an ai (not the kind what ive explained in my previous mail today :D ) the most important thing is to be able to read understad(?) and modify its very own codebase, thats again a pita with such stuffs as python that is huge bloated and has too many sugar included... taking a lotsa various modules would make a huge mess cuz of the various coding-styles, and thats not really a good stuff, but with an universal parser+graph handler, its not that hard to extract essence from here and there in case of heavy lifting or reshaping things without tearing the roots (that gives an another kinda pain when it must be done more than once). using the right tool to the right job brings in just that serious pain that ive talked about above, on besides with the article i started my writing with. its good for some cases, but actually not that much... especially when u wrote something in python but next time u need it in bash and then c++ and then in br*infuck and that way u must reimplement all of ur precious gems that once were considered to be ready.

really much ontopic:
one thing that really makes us love lua, is that its really flexible, we have different style, need, u name it ... and that n+1th implementation is really necessary to keep this spirit, making too much standard stuffs could slowly take this away. lua is the just enough fund, and this is good, and this is why we love it. otherwise ive got no idea what area of coding falls far from lua, there are multiple gaming engines, there are various guis, there is torch for current "ai" stuffs, there is gpu rendering, we have an awesome browser (luakit), phone centers and self-driving cars use lua, cern as well, we have everything that can be wished for networking (even wireshark and nmap) we have lua-users and luarocks to find these gems, we have nice resources (thats started right with the best refman out there), and we have every single c lib!!!!! we have uncomparable power by the nice c api, all the goodies included in luajit, the flexibility of the metatables, that i dont even use cuz i already has enough flexibility without the need for going farer, but i say they are nice to have...

lua is bound to c99, and this is the right choice for the right flagship that is belongs to, above that, much pain comes. and actually it is a hacker paradise and fund, if it would require any less hacking, then it would become an untouchable bloatware sooner or later, and ppl who need a language to be hacked will choose lua even tomorrow, and there are no much ppl around who hack python internals or who would try to fork and modify c++...

i think that one thing to spread the word is to express better that lua isnt just a language to embed cuz it cant make things done on its own... the other one is to laugh at the hype out there and enjoy the party here! :D

uhm, sorry for the amount... bests to all of u folks! :)


Sent with ProtonMail Secure Email.


‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On 2020. January 19., Sunday 18:43, Pierre Chapuis [hidden email] wrote:

Here it is. We're asked "why should we enable Lua as a general purpose
language?" Pierre used Lua's natural speed to make it a better CGI
language than PP&R. Imagine how many more of us would do this if Lua
had tested and curated packages for DOM, XML, and the like, so that you
never have to spend time evaluating competing softwares, and whatever
software you write is likely to have its dependencies available
anywhere the Lua Standard Library exists.
The existence of Python doesn't make Lua useless as a general purpose
language.
Sadly, I have to admit something though: today if I have to choose a
backend stack for a serious Web project it will probably be Python-based,
and I use Ruby on Rails at my current job.


Pierre Chapuis

Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Αγαθοκλής
In reply to this post by Eretnek Hippi Messiás
On Sun, Jan 19, at 07:15 Eretnek Hippi Messiás wrote:

> Αγαθοκλής, what do u mean by self-healing systems?

When (in the winter of 2012) started to write my first interactive application, that
was intended to serve as a common environment for indepented commands (something like
a shell), every function at the begining was running through an interpreted function,
which was simply a try/catch block. The second thing was that those functions were
actually stored in the disk, so i could modify the function and re-evaluate while
the application was running.

It was fun to see the system evolved in real time and to change behavior with the
new input. With time such functions, that proved to be correct, were moved to the
core.

In the next application, the main difference was that every function was stored in
a dictionary, but the procedure was the same. The interpreted function, was able
to produce a detailed message that pointed to the line of the falling function.
The second thing was to supply the application with an evaluation console, and
re-register the fixed function to the dictionary and re-evaluate.

At the very least this produced an environment that was evolved/fixed in real time,
and the development was pretty fast. You can say that it was following the waterfall
model as a test model, and you could dare to say that was a self taught system that
learned from its mistakes (and with a little bit help of its friends (its users), so
you can say that is not actually the self! (unless you and the program considered as
the same:  but you can dare to say this; as the program knows your habbits (everyone
if you think, has a routinary workflow), is tighted with you with time, if has the
necessary tools).

But, if you go a bit more far, and to able to handle failures outside of its code
conditions (various inputs), then you might need to feed it with some choices, like:

I do have a malloc wrapper, that calls a handler on out of memory condition (i know
that is the fchrome browser that eats my precious memory in this old computer), that
exits gracefully the programm (by cleaning up resources) and with a detailed message.
For now it doesn't return control to the block that tried to allocate memory, but i'm
gonna try (if time is generous) and see what happens after reclaimaing the memory back
while killing first this process. I guess if you give in that handler, a priority table,
it can do the killing stuff by itself (as i do not care much for the .chrome browser).

I guess what matters here, is first the diagnosis, and second the tool to be able to
repair itself without bringing down the system, and:

> ... the code that can handle a failure must already exists somewhere in that case

Yes, it was that simple thing was thinking about and not so for a system that can
predict or to produce new code to handle infinite input. Note, that i do not think
that is too hard for a certain algorithm to try cases untill find its limits, or to
a realistic end, and produce a new self algorithm that handle all those cases. Of
course such combined algorithms under an environment, that might have a sense of
this environment, we might call it as an intelligent environment. Nothing wrong with
that i suppose, but can we totally trust such a system and human critical jobs relly
on its predictability? I think, no. Probably because of the evolution. It's like
a new bright input is born when you reach the known finite. Unless of course there
is an end! And probably there is. And if not, who cares! The Known is already much
and the most of all quite Unkown to most of us. There is so much strangeness in this
world. See for instance this month Lua mailing list messages. There was one thread
for "dead batteries", one for "Is Keppler project dead" and then we learned that our
friend Dirk left his body. Then you said that Dirk is not far as we might think, and
then the same day, there a couple of posts from an author with a nick named "Dark".
So based on that, probably Dirk is still on the Dark side, but is not so far away
as we might think. And still i believe that we aren't far away from the moment, that
we'll learn with proves, that our current conscience is never lost but we carry it.

Note that all this complexity or strangeness or absolute madness (called at your
wish) should probably obey (and quite logically (as it has to be controllable and
reproducible)) in simplicity. So what our duty is to discover this simple thing
that governs the creation and use the mechanism.

And speaking for simplicity. Lua is simple. And when you are talking about Python,
is that you turn things up!  Python is the one that should dream about Lua and not
the other way around. If Python and Lua, as they are now (the core language i mean),
started right now their career, who would you think that it would dominate the world?
We all know that. So i guess there is a hope that if you got it right and fight for
it, Lua can become mainstream. Note, that i believe that Lua already is mainstream.
When people talking about embedded languages, the first one ALWAYS in the list, as
a reference, is Lua. You have the machine. Be clever!

Have a good time.

Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Lorenzo Donati-3
In reply to this post by Sean Conner
On 19/01/2020 01:47, Sean Conner wrote:
> It was thus said that the Great Lorenzo Donati once stated:

[snip]

> Yes, pretty much.  It's popular, so I must learn it.  Who uses Lua?
> Why bother with Lua when that limits my job prospects.
>
> On the other hand, going with Python (or any other hip new popular
> language like Go) you are now competing against scores of other
> programmers who know just as much as you do.  The Lua jobs might be
> few and far between, but I stand a better chance of landing them that
> a Python programmer.
>
> But who thinks like that?
>


Please, consider the fact that my original post was made because Lua
team once said they wanted Lua to become more popular. Whereas the hard
data show it is not going that way. Otherwise what I said seems a series
of objections against Lua in itself, which are not.

Some years ago I remember someone linked to a similar SO survey and Lua
was among the top three scripting languages together with Javascript and
Python. Now it's not even on the radar!



>> Ask yourself: would you (a company) prefer a Python solution that
>> is bloated and slow, but still "fast enough", well supported
>> (because "everyone" know Python) and that is created in 10 days, or
>> an equivalent Lua solution that takes 2 month to be created and
>> that cannot be supported long term because you don't even know
>> where to find an alternative Lua dev in your area would the need
>> arise? Not to mention the level of support of libraries.
>
> It's funny you mention that.  I used Lua for a few projects at work
> (one is very imporant (such that it's the front end to the actual
> product that generates *all* our profit at the company) and yet, I'm
> only one of two programmers there that know Lua.  Our QA engineer
> keeps using Python for running tests because he finds it easier to
> use than Lua (despite the fact that most of our testing tools I've
> written were in Lua when I was in the QA department).
>
> Changes to my part of the codebase usually take on the order of
> hours, not days or even a few weeks like some other parts (written in
> C and C++).  I mainly attribute that to Lua's coroutines, since the
> main logic of the program (which is event driven using select() [2])
> looks more like imperative code than chopped up callback hell or
> asynchronous promises or whatever the new hotness is in nodejs these
> days.
>
> Also, back in late 2018, a new project was announced.  I (by myself,
> on my own) managed to write 90% of the code base in Lua in two days
> (the last bit wasn't done because of some still open questions).  The
> other team that actually started writing the code took the better
> part of a year (I think---I'm not entirely sure they're done yet) to
> write the program.  But hey, I program in Lua, what so I know?
>

Yes, from your POV you are HUGELY productive with Lua (and that's why
I'm /not/ bashing on the language - heck! I LOVE it). But from a
management POV you are (seriously) a potential liability: if you decided
to leave the company they would be seriously sc***d up, unless there
were a ton of expert Lua programmers around ready to jump on board to
keep care of the code you wrote.
(BTW: how much of your Lua coding requires interfacing with C through
Lua C API?).

Moreover, ask yourself if a company wanted /now/ to invest in a new
language, would they choose Lua (even if (a) they needed something where
Lua shines and (b) they knew about Lua altogether)?

Of course if you already have a huge codebase in Lua with good senior
programmer/s/ (note the plural), you would think thrice before making a
switch.

But still, if a technology is going to be obsoleted [1] by market
forces, that's an important factor in management decisions (remember
those firms stuck to maintain huge COBOL codebases in critical systems
that paid big bucks for the few greybeards that still knew it?!?).

A good technical manager should be able to see that a technology is
going the way of the dodo and plan for its timely replacement.

I'm not saying Lua is obsolete because it is bad, but market forces have
(almost) nothing to do with what is good or bad (sadly). If a product is
badly marketed there is no hope it would be able to compete (especially
on a large global scale).

It either survives in a niche or it dies off.

The world has seen a lot of extremely good products (HW and SW) that
went down the kitchen sink despite their technical merits because of bad
marketing moves. And hype, for good or bad, is part of the market forces.

And being open source doesn't make Lua immune to market forces, it just
keeps one of the factor (licensing fees) out of the equation.

>> Again, Lua is better at some things, but that doesn't make it a
>> "good" general purpose PL (and being Turing complete doesn't count
>> in practice) if people don't /use/ it as a GP-PL.
>>
>> And, btw, this huge user base means that Python use is growing even
>> in areas where Lua definitely shine: embedding. I find more and
>> more projects that use Python as embedded language. I can't say how
>> difficult is to embed Python, but I'm sure that if the demand
>> grows, someone in the Python community will find a way to make it
>> simpler.
>
> And here I thought that Python was shedding users to Go, because of
> similar easy of use plus it runs faster (and is just as opinionated,
> if more so, than Python).
>

Python has a huge advantage wrt. other competitors: it appeals to
non-programmers. Go aimed at being a new system language, maybe
replacing C in some areas. They were targeting professional devs.

Python has become the go-to language for many professionals /who are not
SW professionals/ (Sci-py anyone?). And they make up a big part of
Python community.

Ask yourself which language would you use if you weren't an expert
programmer with a problem at hand that required some serious programming
that didn't require hiring a professional dev.
"Hey everyone is talking about Python. Let's try it!"


>> I really think Lua Team should reconsider some of their positions
>> on the development model of Lua, otherwise they risk a slow descent
>> into irrelevance in the PL landscape in a couple of years (except
>> maybe some very limited niches).
>
> They might not even care.
>

Well, that's the feeling I got in latest years. But in this case it
would be nice for the community to know their new stance.

If they no longer want Lua to compete on par among the GP scripting
languages, but they want Lua to become a niche language or a simple
research project for their academic purposes, that's perfectly OK, but
the community should be made aware of that. [*]

Because otherwise (i.e., they want to compete on that field), and that's
what I'm arguing about, they have been making the wrong moves, IMHO.


> -spc (Never been one to use the popular stuff ... )
>
> [1] https://blog.osteele.com/2004/11/ides
>
> [2] Well, poll() actually on the production server, epoll() on Linux
> and kqueue() on Mac, but the later two are mostly test platforms.
>
>

Cheers!

-- Lorenzo


[*] BTW, although I appreciated some new features in the evolution of
Lua from Lua 5.1 to Lua 5.3 (e.g. goto, operators). I really didn't
understand some decisions: string.pack/unpack, half baked utf8 library?

These seems very specialized tools that would fit very well into an
external library in the current Lua philosophy. Yet they were included
in the standard library. Why? Who knows!

And the new features of Lua 5.4 ... well I'm a bit perplexed. Some
mechanism to handle RAII more deterministically is very useful, but the
syntax complications seems a bit ugly to me. But I didn't try it, so
it's just a gut feeling.








Reply | Threaded
Open this post in threaded view
|

Re: was: Some info about Python: Back to batteries

Dennis Fischer
In reply to this post by Pierre Chapuis
I may be a bit biased, as I am in the process of writing my own
framework for this, but I consider Lua very viable for everything
web-related.

I've played around with OpenResty+Tarantool+Fengari quite a bit and
there's something about it that just feels right. The only thing that
still annoys me about it is that Lua doesn't natively run in the
browser, but that's very likely to be a non-issue thanks to web assembly
sooner rather than later. Now that LLVM supports WASM as a backend, the
hordes of rust fanboys will only accelerate that process.

The only real problem I see is completely unrelated to any of the
implicated technologies; it's the staff question. Developers learn
python because companies use python. Companies use python because
developers know python.

On 19/01/2020 18:43, Pierre Chapuis wrote:

>> Here it is. We're asked "why should we enable Lua as a general purpose
>> language?" Pierre used Lua's natural speed to make it a better CGI
>> language than PP&R. Imagine how many more of us would do this if Lua
>> had tested and curated packages for DOM, XML, and the like, so that you
>> never have to spend time evaluating competing softwares, and whatever
>> software you write is likely to have its dependencies available
>> anywhere the Lua Standard Library exists.
>>
>> The existence of Python doesn't make Lua useless as a general purpose
>> language.
> Sadly, I have to admit something though: today if I have to choose a
> backend stack for a serious Web project it will probably be Python-based,
> and I use Ruby on Rails at my current job.
>


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: was: Some info about Python: Back to batteries

pocomane
On Mon, Jan 20, 2020 at 5:52 PM Dennis Fischer
<[hidden email]> wrote:
> The only thing that
> still annoys me about it is that Lua doesn't natively run in the
> browser, but that's very likely to be a non-issue thanks to web assembly
> sooner rather than later. Now that LLVM supports WASM as a backend, the
> hordes of rust fanboys will only accelerate that process.

Actually it is already very easy to compile lua for wasm, e.g.:
https://github.com/pocomane/walua .

Reply | Threaded
Open this post in threaded view
|

Re: was: Some info about Python: Back to batteries

Pierre Chapuis
In reply to this post by Dennis Fischer
> The only real problem I see is completely unrelated to any of the
> implicated technologies; it's the staff question. Developers learn
> python because companies use python. Companies use python because
> developers know python.

It's my main issue as well.

The 2nd one would be the ecosystem. Things like PaaS hosting,
APM, ASM, crash reporting software etc tend not to support Lua.

For smaller projects, I don't care, but as soon as the team scales
a little it makes it hard to pick Lua.

It's certainly possible though, very large websites do run on Lua
(including Taobao...).

--
Pierre Chapuis

Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Sean Conner
In reply to this post by Lorenzo Donati-3
It was thus said that the Great Lorenzo Donati once stated:
> On 19/01/2020 01:47, Sean Conner wrote:

  [ snip ]

> >Also, back in late 2018, a new project was announced.  I (by myself,
> >on my own) managed to write 90% of the code base in Lua in two days
> >(the last bit wasn't done because of some still open questions).  The
> >other team that actually started writing the code took the better
> >part of a year (I think---I'm not entirely sure they're done yet) to
> >write the program.  But hey, I program in Lua, what so I know?
>
> Yes, from your POV you are HUGELY productive with Lua (and that's why
> I'm /not/ bashing on the language - heck! I LOVE it). But from a
> management POV you are (seriously) a potential liability: if you decided
> to leave the company they would be seriously sc***d up, unless there
> were a ton of expert Lua programmers around ready to jump on board to
> keep care of the code you wrote.
> (BTW: how much of your Lua coding requires interfacing with C through
> Lua C API?).

  Hard to say.  I have to use some of the POSIX stuff (network IO, select(),
reading time at millisecond precision (or better)) and there is some C glue
to some specialized data files that *could* be done in pure Lua (5.3) but
due to resource utilization (we mmap() the files beause they're shared among
several programs) and the pain of reading binary data in Lua 5.1 (there's
the reason for string.pack()/unpack()).  Oh, and LPEG---parsing of SIP
messages (lots of text).

  But the main logic is in Lua, and because of coroutines, it's all
imperative, this, that, theother type sequence which makes for easy
modifications of the main logic---the same *can't* be said for the other
components written in C++---there's it's a nightmare tangle of state
machines all over the place.

  Yes, I am aware of the view from management, but so far, it's never been
an issue (my first and third manager (same person) didn't care, my second
and fourth one (same, but different person) didn't understand what our
department actually *did*, my fifth manager put my Lua-proof-of-concept (I
was using Lua at the time for prototyping purposes with the intent of maybe
rewriting it in C when the logic was hashed out) into production without my
knowledge, I didn't have a sixth manager (long story) and I'm now on my
seventh manager (yes, seventh---number six wasn't an official manager,
again, it's a long story) who is close to retirement anyway).  And my record
of quick turn around times speaks for itself---unlike the turn around time
for the non-Lua components.

  If I leave, is the company screwed?  Not really, as the only other Lua
programmer works in our department (he uses Lua for configuration, not main
logic).  On the down side, with the exception of me, the entire department
is near retirement age, so in a few years the company will be screwed anyway
(let's see, Lua, C89 and C++98, lovely mix of langauges there 8-/

> Moreover, ask yourself if a company wanted /now/ to invest in a new
> language, would they choose Lua (even if (a) they needed something where
> Lua shines and (b) they knew about Lua altogether)?

  Gaming companies seem to like Lua.  It's also in Apache and Redis.  So
it's out there.

> Of course if you already have a huge codebase in Lua with good senior
> programmer/s/ (note the plural), you would think thrice before making a
> switch.
>
> But still, if a technology is going to be obsoleted [1] by market

  I think you forgot your footnote.

> forces, that's an important factor in management decisions (remember
> those firms stuck to maintain huge COBOL codebases in critical systems
> that paid big bucks for the few greybeards that still knew it?!?).

  Yes, and we're trying to get away from some legacy code ourselves (SS7).
There's nobody left in our company that really understands it.  There is a
department that works with SS7 at our parent company, but they use an
entirely different SS7 stack than we do (theirs is homegrown, ours is
purchased, not sure which one sucks worse).

> A good technical manager should be able to see that a technology is
> going the way of the dodo and plan for its timely replacement.
>
> I'm not saying Lua is obsolete because it is bad, but market forces have
> (almost) nothing to do with what is good or bad (sadly). If a product is
> badly marketed there is no hope it would be able to compete (especially
> on a large global scale).

  And in my department, I'm surprised we didn't use Erlang.

> Python has a huge advantage wrt. other competitors: it appeals to
> non-programmers. Go aimed at being a new system language, maybe
> replacing C in some areas. They were targeting professional devs.

  From what I've seen, Rust is pulling away at the C programmers and part of
the C++ crowd, Go is pulling away Python users and a part of C++
programmers, with Swift pulling away programmers who work with Apple
products.

> Ask yourself which language would you use if you weren't an expert
> programmer with a problem at hand that required some serious programming
> that didn't require hiring a professional dev.
> "Hey everyone is talking about Python. Let's try it!"

  I can't answer that as I'm an expert programmer.  And if I'm honest, if I
were a 15 year old kid, I"m not sure I would even have an interest in
programming these days.  Long gone are the days of turning on a computer and
less than a second later (and that's key) typing

        10 PRINT "HELLO SEAN"
        20 GOTO 10

> [*] BTW, although I appreciated some new features in the evolution of
> Lua from Lua 5.1 to Lua 5.3 (e.g. goto, operators). I really didn't
> understand some decisions: string.pack/unpack, half baked utf8 library?
>
> These seems very specialized tools that would fit very well into an
> external library in the current Lua philosophy. Yet they were included
> in the standard library. Why? Who knows!

  string.pack()/unpack() I agree with, but the UTF-8 changes were not just
limited to the utf8 module.  There are some language changes to allow
Unicode escape sequences.

> And the new features of Lua 5.4 ... well I'm a bit perplexed. Some
> mechanism to handle RAII more deterministically is very useful, but the
> syntax complications seems a bit ugly to me. But I didn't try it, so
> it's just a gut feeling.

  I have similar feelings, and I feel that Lua 5.4 isn't that compelling to
switch to (but it will be easier than the switch from 5.1 to 5.2).

  -spc

Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Sam Putman


On Mon, Jan 20, 2020 at 6:55 PM Sean Conner <[hidden email]> wrote:

> Ask yourself which language would you use if you weren't an expert
> programmer with a problem at hand that required some serious programming
> that didn't require hiring a professional dev.
> "Hey everyone is talking about Python. Let's try it!"

  I can't answer that as I'm an expert programmer.  And if I'm honest, if I
were a 15 year old kid, I"m not sure I would even have an interest in
programming these days.  Long gone are the days of turning on a computer and
less than a second later (and that's key) typing

        10 PRINT "HELLO SEAN"
        20 GOTO 10

If you were a 15 year old kid, there's a good chance you'd be playing Roblox.

It has 100 million active users, putting in one billion play hours per month.

If you wanted to program it (and it's oriented around this), you would instead do this:

    1) Click Create in the blue bar at the top of the website
    2) In the My Creations tab click Games if it isn't already highlighted
    3) Click Create New Game
    4) Choose the settings and templates for your new creation
    5) Click Create Game

    And, of course, you'd be programming in Lua. 

    cheers,
    -Sam.
    Reply | Threaded
    Open this post in threaded view
    |

    Re: [mildly OT] Some info about Python

    Eretnek Hippi Messiás
    In reply to this post by Αγαθοκλής
    hi folks! :)

    this will be somewhat even more offtopic, but its still about the real power of lua, there will be bits between the lines that are related to some of the ongoing topics, and probably it will contain stuff that i already told on the list, so feel free to skip it, u wont lose much ontopic, or just wait until the night comes, make a strong coffee, and take some smoking breaks like how i do it :D (warning has been given, even if i would say that it can be interesting and valuable on a different way than one would wish for here, but i cant decide in the name of nobody else, and none will know til the end if it worth the reading or not..... :D but sorry for the upcoming length anyway, and please dont hate me, cuz i gave the warning! :) )

    (otherwise i think everything is interconnected to everything else here and beyond and the threads cant really represent such, and imho it doesnt really worth to break the already ongoing subtopic, and i even tried to do so recently, but i only got a response in an another thread with a pointer to my isolated message... :D so i dunno what would be the best way, and i think its still just kind of a "pub", even if its a leet pub! :D
    otherwise/2 Dirk was the one who said that he liked to see when we exchanged more loosely connected thoughts with Alejandro about our apps after i offered to continue that discussion on a private channel, and i also hope it can be more-or-less valuable to the rest of us as well :) )

    so, Αγαθοκλής, i really liked what uve said, i could see that we are governed by the very same higher spirit, and i late a bit partially cuz i wanted to dedicate more time and attention to this response :)

    > > Αγαθοκλής, what do u mean by self-healing systems?
    >
    > When (in the winter of 2012) started to write my first interactive application, that
    > was intended to serve as a common environment for indepented commands (something like
    > a shell), every function at the begining was running through an interpreted function,
    > which was simply a try/catch block. The second thing was that those functions were
    > actually stored in the disk, so i could modify the function and re-evaluate while
    > the application was running.

    i see my app behind ur words, except that mine isnt like a try/catch, its got a top menu to control the app and the current doc (or code), and a sidebar menu where the docs can be selected (currently core, lab and notes, that i just wanted to make more granulated with the unfinished and partially lost rebase to a tree), and an editor and an output box. its flow is like write/modify the code -> then hit ctrl+r for running it (ive made recently a magic infinite loop breaker (simpl `brk()`), its based on the line number (automagic) or any id i give it, and on an iterator counter that can be set or will default to 1000, and that could be time based or both, so later i can make it keypress based without crying every time i just start to write a loop... :D in case of a fail, it triggers an `error()`, so it can escape the loop, and go back to the `xpcall()` where i started the game from) -> it will be saved before the execution against loss by any mistakes, then it will be run via `xpcall()` that gets a slightly modified version of `debug.traceback()` (thats compatible with the original one, based on the 5.1 sauce) just to elimintate the trims of the paths (to find the right files easier, i also hacked `require()` and the like to know what i actually have) and to not trim the middle of the longer traces (i think those are clear antifeatures in lua, that i cant fix from pure lua in the actual error message as well), and then it will optionally print a header with some general info (another black magic, i can insert stuffs into the output buffer after execution, such as exec time, mem usage and new/changed/deleted globals (only those; and optionally; and cuz a missing `local` or whatever :D ), but its just based on a concatenated buffer, where i insert empty strings and keep the location of them :D ), and print either the output or the error message that will contain also snippets of the files in the traceback with line numbers, a cursor (like "100> " instead the default "99 : "), and a few lines before and after the line that is given by each row of a traceback (multiple cursors are allowed, according to the related traceback line, it wont even duplicate lines, nor print everything between distant cursors (this was also used in my search engine that just lost, or better said just sleeping on my half-dead hdd :D ) ; this is done outside of the hacked `traceback`) and i also reset here the counters of the loop breakers, but i think i can move those resets after the related loops, so i can keep them after finalizing stuffs (read as moving to core :) ) btw the pcall stuff and the reset of `brk()` can be excluded and the rest can be used to run c, bash, whatever, but mostly those, cuz linux lua c and bash are enough for everything. (sure, asm, frontend bs, db languages, and hw description languages werent considered there)

    once anything is in the core, it can be either put back to lab to hack more on that, or it can be run on a similar way, but actually i will make a 2nd instance in that case with the modifications made there (no problem with the multiple saved versions). i have actually two kinds of save, one is permanent (under the directory "save"), without deleting any of them, thats made by hand, the other one is called to be "history" that is rotated on every run, where i save currently 50pcs of them. core runs the last version of "save" and shows "history", and running a 2nd, or whatever instance (or instance of an instance) uses that modified version, or will also print an error message if it wont run. tekui have `Application.up()` thats just an empty overrideable function as the last function before entering the event loop, so i also test if it can run up to that point (and exit from there) before i would let it to be saved, so it cant be rendered to be unusable, but it can malfunction, that i test by hand currently (and cuz of 4 mistakes in a row i could lost a whole day of intensive development once upon the time, but its really hard to make it crash/unresponsive/loss any data :) ). cuz of the instances currently has the same directories to save, i can hack around them, but actually this is the 2nd valid usecase ive found for metatables, as those could make some pretty magic to avoid this at will (currently i dunno my exact plan with them, my app has a high mental load with much plans, considerations, and complexity here-and-there, thats still better than bloatware, and even bigger complexity where i must jump between thousands of 3 line functions :D - i believe in naming, formatting and in comments should be the solution, not the very-"clean code" 3 line function littering... :D 11th commandment: „Thou shalt not litter.” - in memory of Terry A. Davis - my ideal :) ) ; the other one was related to the string based function assembler and/or serialization that doesnt like functions (it can be done without upvalues, if i want to save ugly stuff, but i dont...) so that way i could save the strings before evaluating them, and the metatables was for keeping them with the functions as weak keys, but finally i didnt need that...

    > In the next application, the main difference was that every function was stored in
    > a dictionary

    thats my current approach, that i wanna turn into a tree, so i can have interitance fallback and whatever, where nodes have fixed fields with a '_' prefix, and the rest is the continuation of the tree, where i can have fields for config and the bidirectional dependencies that i can serialize, docs, the codes, the runtime data that can be regenerated but cant be serialized, tests like the codes, that will prevent me to f*** up things like the save function that also deletes the older saves (based on timestamps, where i can overwrite a save thats made in the same second, but who cares :D i hate that git uses meaningless random strings that are represented often as a part of them that could collide much easier, and i can add to these metainfo like what semver represents <- u see guys, its ontopic! (just a different one :D ) ; i could also limit the loading to a particular time (that probably asking for some pain around the saving), and from the perspective of git, they could wait a second to not collide, or same seconds could get a suffix like ".1", ".2"..., and also a prefix "username/" (and its pretty, simple, meaningful, and isnt bloated :D ))

    > At the very least this produced an environment that was evolved/fixed in real time,
    > and the development was pretty fast.

    yea, i feel those words! :D even if i have a really small code base, that i refine more than how much i "extend" it... my functions are like small "freestanding" programs on their own right, instead of doing that on an class/object level with a bunch of small function, this helps me to keep the codes really small, compact and coherent, and then i isolate parts when something is needed elsewhere as well, so while unix has small apps with a few kilos/megs to serve one purpose i have small functions with 10-80 lines, that are made "digestable" (yep, the "sauce"... X'D ) by comments and formatting. :) (btw i wrote above "freestanding" like that, cuz they are highly interconnected.)

    > so you can say that is not actually the self!

    i think self-modification has levels, the basic level is when u set a variable in run-time, and then the behavior will change accordingly, the 2nd level, is any kinda autodetection, the 3rd is when u make that permanent, by any kinda serialization that u save, and the 4th, and real, level is when the app actually makes real permanent change in its own logic, like validating/modifying/extending its own functionality beyond simply flipping a switch, according to a self-created or a user-given aim. i think this is already near to an ai, just its not necessary general, and its not a big difference if the will comes from the user or from itself, but i think the key is just the ability, not the intention, that can be given as an initial spark, like for a perpetum mobile (that doesnt exists, cuz its misnamed, and only "field-energy-extractors" _exist_ that can give more output than their initial input, but thats an another topic :D ) ... so yep, i think its a more healthy way to have an "assistant" ai than a selfmotivated one, but the border is thin. actually it was hard to find the name "assistant" thats the name of my "ide", i only had the names Szoszi (umbrella name for the whole game (that is written only once in my codes, and that is the only meaningless name, everything else has general names...)) and core and lab, but i want a server for example, and i had to give a name for the other part to be able to organize the codes in a tree :D ive just let the word on a loose leash, but theres something interesting here, the way of building a real ai. write some functions for some tasks, use them, make them use eachother, and one day realize that ur not just executing useful functions but command an app to make the research, ease ur work, and become a commander of some kinda more or less autonomous entity thats just a matter of will to ask a thing thats more than what the current dummy apps can do, on more and more general purposes. i hate the current "ai" hybe bullsh*t, cuz they are making sharp specialized general tools (upon garbage-heap-messes) for given serious tasks, but they dont purify their garbage-heaps, its all about crystallizing knowledge, and thats the part that really suffers there... one just unabled to extract a single input from those fine-tuned floats in neutral networks. otherwise the functions that i (or any other programmers) write are just purified knowledge-slices that we give to the computers that they know how to work with them. make them able to find, collect and refine data, and to be able to read their own codes, and we are almost there. btw i think that the name "assistant" can be understood by now :) cuz its not just an "ide", its just waiting for the singularity, thats not a miracle, and probably a process, not a point in time, even if its still not that much near... and about the original topic (lua) i wouldnt do it in an another language, cuz of too many trash, while this much functionality is not just enough, but its way better, and im not afraid of talking about this much details, cuz ppl from the nsa/g**gle/what not (shit, i still dont have enough security, but hopefully also dont have enough codes) would try to play the same game in js and python and slowly bleed out :D and about the other ongoing topic, i wanna make that `help()` thing (just more likely under the name `doc()`) but that will also rely on much of my codebase that i still wouldnt share by now (arguing on it is always welcome, but thats just an another long topic to know what u should argue against :D but it will be free and i wont be able to make everything on my own, but i wanna make the groundwork the right way (dunno either if it exists, but these funds are awesome :D )) .... so `doc()`... refmans are interesting beasts, they are different than reading Shakespeare, they are more similar to codes, and we have learned how to make their ast, so the point is that i wouldnt stop there, but i wanna make project-level and global dictionary with the occurrences, give explanation for abbreviations, group related things by naming conventions, by parts of speech (+whatever), find rare words and replace them with often-used ones, match correct words with slang, typos, translations (+?), and then it can be used for various purposes, like sanitizing codebases, guide newbies, teach ai, and whatever, and that way theres a chance that one day free speech can be used for programming on a very exact way (instead of based on statistical _odds_ :D (pun intended)) btw if im already about some ontopic stuffs, then im actually avoiding as much external dependencies as possible to make everything homogeneous on the same funds, that play kind with each other, and that are well-organized, while, for example, the server wont load the desktop gui (except if i want it explicity for various crazy ideas? :D ) so it wont be a real bloatware, but like an operating system where i can have thousands of apps installed without running all of them always...

    but, sadly(!), currently i can only share ideas, maybe some gems, as i must protect critical plans, like the e-democracy and ai stuffs from becoming weapons of mass destruction in the hands of any of those enormous profit oriented organizations, let it be a whatever tech corp or agency or governance, when we are already talking about ww3 and a whole continent is burning after the amazons, like if the apocalypse would knocking our doors, and when i wanna make a better world, instead of offering a new toy for those who are sucking out the blood from our mother earth and our brothers and sisters all around for not a few $$$$$ but while they already cant spend their money in a lifetime, while others are happy with a dry mustly slice of bread from the bottom of a trash bin, so it must become mature before it could go out to the wild, instead of getting some bloat, makeup, and paying gates for the leet pro subscription... yuck! yes, we are actually digging our massgrave, and we are near to the bottom of it, who cant see it must be liar, even the blind and dumb see, know and feel it. so just sorry for stealing here-and-there a few lines for some of my crazy repetitive offtopics, but actually u, folks, are those ppl who are in the 2nd line of the nearest places to the campfire, right after (with a very few) my nearer geek friends, or maybe even nearer with a bit, as they have heard more but not much switched to linux (cuz of security and the ability of customization) and lua, cuz of the perfect fund for the best kinda mad-science! ;) (even if they wouldnt ever see Szoszi in action...) read it as i will need some ppl to join before it will become public, for benefits coming from a private swiss army knife to hack around their private stuffs, to developing for income, for anything like teamwork and sharing whatever private swag with other users, or with the world or friends via the server (as these can be done without letting the control out of our hands while enjoying benefits) ... but with actual limitations, so there is the downside of it just as well, and i still need more funds to reach that point, as currently it would bring chaos into the development... i only know that Gaia is bleeding, and the need for this is real, and that i cant see anyone around like i could think whatever like "huh, kawl, some1 will save us from ourselves, and he/she/whatever does it right!" not even TAD did, aka God's lonely programmer, or the Dalai Lama, or the united nations, or Trump or whoever else who can be seen near and far... even if i can see brilliant masterminds with good intention, with the right direction and what not - but still, i wholeheartedly respect them and bow my head in front of them!

    and, not even me alone! ... and if i went this far, i cant just stop here, but dont stop the reading just before the end of the current paragraph, and say that im just an another crazy guy and u already know my type, cuz im obviously crazy, and thats not in question! :D so my name, Eretnek Hippi Messiás, means Heretic Hippie Messiah, and this really requires explanation after all the things ive told so far now by the years... i dunno neither if im the messiah or not! maybe. maybe im the antichrist, as im a heretic, maybe really (i know im not pure all the way down), maybe just in the eyes of the status quo that i think is rotten inside (sorry if not, and sorry for the exceptions cuz of the generalization!) im a hippie, cuz im with the ppl, with a big hearth and good intention, but my name takes either all three strictly together, or just hippie, cuz i love the humanity and my soul can be described like so. so yep, maybe im just plain crazy, i cant even see my past lifes, i cant walk on water even if i own some higher level real magic. dont forget about my very own uncertainty about myself! (thats just another pillar of being heretic.) only time can decide, and maybe i will be the one who will lit the wick before the final big boom, but there is the chance that i will be the messiah, either by being identical with whatever we can think about it, or just practically, out of the need. actually i prove much on much areas of life, i got really much hearth-heating feedbacks, but any1 with high aims can do that... ive got even more offtopics on the list of my plans, to make the world a better place, not just those im continuously talking about, just as well as about myself and the related stuffs, but my current intention was just to tell how i see myself - those big words really required that!

    > you could dare to say that was a self taught system that
    > learned from its mistakes (and with a little bit help of its friends (its users)

    you say it has users, i dunno if thats just a saying, while means u, or it has/had(? that would be sad!) some private users, or if its public, but now, as u know enough about me, my work, my intentions and the like, may i have a look at it? :) i dunno what could/should i promise, i can only say that i dont collect enemies and i dont wanna harm ur path, and actually im interested in it conceptually while my concepts are there without more obfuscation than whatever mess lives in my head :D i hope that i can help u pointing out good places for further development in return, and as i really like the whole thing uve said, u also have good chances to be one of the 1st guys who can play with my toy. :) but note all the above to that! like its still not ready to make it happen any day now and i really dunno when that day will come, and i early adopters will need to have limitations, etc (theres much more to say about these...) in that case i would make a really long conversation with u to not reveal u surprizes halfway, and to align our wills about anything related important considerations...

    > I do have a malloc wrapper, that calls a handler on out of memory condition (i know
    > that is the fchrome browser that eats my precious memory in this old computer)

    i think there are easier solutions, like u can limit its resources, u can use oom killer/reaper, but actually this isnt that much straightforward, cuz it can still eat much while u can run out of that limited amount of memory, but for a lua script, its most likely enough to provide a few free megs, and, with enough swap, u can do the dirty work just on a somewhat slower machine instead of pushing some big red buttons :D and yep, maybe the opposite of the limits exists, and u can provide a minimum just as well, but ive never looked after anything like so... (ive got 4gigs of soldered ram with sometimes more than 1000 tabs opened in firefox, so i know that feeling :D ) otherwise its not always fun to just kill firefox, i dunno if the case is different there, but ive lost 1 or 2 times my opened tabs that way...

    > Python is the one that should dream about Lua and not the other way around.

    THAT!!!!!!! this is as much true that it could be the end of the ongoing flame war driven by the creep of the plain ordinary hype :D
    btw, some ontopic: im in a hungarian general purpose programmers' group with more than 10k members, where beginners always appears with the question: "which language they should learn?" python has a prominent place in the list of the general suggestions, and also, ive learned it cuz i wanted to teach an ex girlfriend to codefoo, while i was a hobby frontend dev, knowing that html+css+js+......... is an overwhelming set to learn, so ive picked up python to teach her... when its my turn, i tell them its good to learn python as it is all around, but this way any language can be good-to-know when their turn comes, while i also tell them that lua is the most awesomeness in the known universe (right, im doing it with a flood of reasoning, u know... lulz) but i tell them to learn something else 1st to pick up the basics, cuz otherwise they wont see the real awesomeness of it without being able to compare it to other stuffs out there in the wild...

    > So based on that, probably Dirk is still on the Dark side

    the things uve said just before this tells me about a very important ability that im not sure if it can be taught, but i think it requires the right soul eyes to see, be proud! :) (and the rest of ur story is aligned with the same just as well :) )
    otherwise, no. actually this is the dark side, if any, but dont commit suicide just cuz of this, we came from there cuz we wanted to come here, and with good reasons, as this can be considered as an extension with special abilities, but that "side" is more essential, and here we are so much limited in many senses, in exchange for some special extensions. but ive just stole some space for these lines, while never enough space could be stolen for them, so lets move on for now with the geek stuffs! :D (ive stole much today, i hope those who already hate me cuz of the amount of distant topics could find some gems in exchange, and that they will remember how i started this message. :) )

    some final ontopic for those, who are afraid about the future of lua:
    - be urself the advertisement, its more valuable than any madeup marketing bs! :)
    - a hungarian common saying: „lassú víz partot mos”, that is literally "slow water washes the coast" (like as washing/moving it away) - grab ur favorite ide, like the actually awesome zerobrane studio, and things that lasts. words come and go, they are easily made, even the fools can take their part in the global noize (just think about that hype, how loud is it), writing codes can take more time than those, but they will do their jobs everyday and will affect the world later, but stronger! once upon the time, before i picked up python, i collected some gems i wrote (in html), and i wanted to write a book, cuz ive said things to ppl that were unique, valuable and appreciated (even if i already laugh upon them as they were nowhere to my current knowledge), and i already had some nice minor ideas to make things better. some time gone past with that aim in front of me, but later, as i got deeper into the rabbits hole, i had to realize that ppl will read the books, and then put them up on their shelves, between the rest of them, and let them collect dust while they are consuming the next and the next of them. not as softwares do, that will serve day after day, that can turn knowledge into practice without requiring much if any human efforts. http://i.imgur.com/Q8kV8.png and for python: https://grahamquince.files.wordpress.com/2014/03/time_work_graph.jpg?w=450 :D

    (ps: im feeling myself guilty cuz i write Szoszi with a capital, cuz the personal attachment, while i only write ppls names with capitals other than that, cuz of general respect to humans, but not the names of other apps, cuz of general laziness (i wouldnt have time to breathe if i would try to write correctly, and when i actually try, my walls of texts become much larger, and therefore not less overwhelming :D ), and cuz i dont wanna lookup some specially written names when im in doubt, and to stay consistent with myself (thats where i cheat for Szoszi), but please consider it as i do, as its really not the lack of respect of ur works - now i feel a bit better, thx! :D but hey, kudos to Lua and all the related gems, with the masterminds behind them! ;) )

    all the bests to all of U dear folks! :)

    Sent with ProtonMail Secure Email.

    Reply | Threaded
    Open this post in threaded view
    |

    Re: was: Some info about Python: Back to batteries

    Peter Hickman-3
    In reply to this post by Dennis Fischer
    On Mon, 20 Jan 2020 at 16:52, Dennis Fischer <[hidden email]> wrote:
    The only real problem I see is completely unrelated to any of the
    implicated technologies; it's the staff question. Developers learn
    python because companies use python. Companies use python because
    developers know python.

    Companies will use Python for a reason. Perhaps those reasons will just be historical, maybe the first application was written in Python when it was less corporate but now you have >10,000 lines of Python to maintain. So you employ more Python programmers to maintain and expand your applications. Substitute the any language for Python in the above and the argument remains. If you are starting something new and there is some existing library that would give you a big head start then you might pick a new language. But it will not make much sense to do so just for the hell of it given that you will be have a massive learning curve for the new field and then adding an additional learning curve for a new language

    In fact it has nothing to do with the language and more to do with the tools available in the field. Lua's field of expertise is being embeddable and as a scripting language within a less flexible frameworks / languages. This has lead it to become a lean language which can be exploited for that outside it's traditional fields. But unless that is absolutely what you need then using Lua does not make sense

    I didn't convert one of our core applications to Lua just for a laugh but because it improved the application many fold (cost / benefit). However there is little benefit to using Lua for our other applications. We have our workflow nailed down just so, we have considerable experience in the tools we use. We cannot throw that away without good reason

    So we will continue to employ Ruby programmers just as others will continue to employ Python, Java and even PHP programmers

    Reply | Threaded
    Open this post in threaded view
    |

    Re: [mildly OT] Some info about Python

    Αγαθοκλής
    In reply to this post by Αγαθοκλής
    On Mon, Jan 20, at 02:41 Αγαθοκλής wrote:
    >
    > And speaking for simplicity. Lua is simple. And when you are talking about Python,
    > is that you turn things up!  Python is the one that should dream about Lua and not
    > the other way around. If Python and Lua, as they are now (the core language i mean),
    > started right now their career, who would you think that it would dominate the world?
    > We all know that. So i guess there is a hope that if you got it right and fight for
    > it, Lua can become mainstream. Note, that i believe that Lua already is mainstream.
    > When people talking about embedded languages, the first one ALWAYS in the list, as
    > a reference, is Lua. You have the machine. Be clever!

    Please, let me allow to hopefully help a bit the situation.

    Currently for non prime programmers (students, teachers, scientists, ...) there are
    two main choises:

      - if you want beauty and expression, Ruby

      - if you want concise and without ambiguities syntax, and preferable "one way to do
        things", Python

    I guess most choose Python because of its clean and easy to understand syntax. It is
    also much easier to learn and it takes much less time to write your first code and
    through any fear.

    For programmers that are looking for a language that is efficient, fast and gently
    with the resources there is a gap. Probably most of them heard and tried Lua once.

    But what are these reasons that do not develop in Lua the killer applications?

    Of course the first reason, is that they want their application to matters in the
    market. A long time support for sure. Both those reasons are missing from Lua.

    The first because is the feeling that get, which is the same feeling you got, that
    nobody cares - this is not true, but it's true also as Lua looks too much like an
    academic toy to them. The last condition is also the second reason.
    There is no built in stone guarrantee. There is no foundation! And the only way to
    change the bits in the code is by monkey-patching. This is great flexibility, if you
    ask me but also a great diverse.

    Speaking for the syntax and the core language, and taking as facts the current state
    of programming languages and the programming evolution (it is important to see it
    that way).
    There are a couple of things that are all facing, that even they don't like at all,
    or they need some time to see the light. You all know them but i'm gonna to repeat:

    The prime and the only type in Lua are tables. It's an absolutelly genious piece of
    code design, but at the same time a bit confusing. This adds overhead in their minds.

    The second thing is this "local" stuff. I'm sorry to say that lessons learned.
    The default scope for any declaration, and this is going to be forever and ever,
    is local scope. In C, fortunatelly recent development fixed this, by given the
    -fvisibility=hidden flag that turn things up/down. That every object, unless is
    instructed specifically, has local scope to the compilation unit. Globals are evil
    and should be avoided and only allow them explicitly.

    The fourth is the lack of a standard library. For this allow me to disagree that such
    a library should be blessed by Lua team. First because of the energy that they have
    to spend, and secondly because, and i can bet for this, they don't use Rocks. So this
    clearly is an omission of the community. Please, we all know that you can handle the
    situation by yourselves. Perhaps this list has the highest average of expertize in
    all the programming universe, because of the plularism in your knowledge in all the
    other domains of programming, even if it is a specific and difficult for everyone to
    grasp, or because you are fluent to many many other programming languages. But we'll
    know, that besides C and the new (very promised) kid in town, zig, give a some kind
    of disatisfaction. So you can't at the same time critisize or to wonder, why Lua is
    not taking the world as it worths to take, and at this same time do nothing for it.
    Simply the answer to this is because you don't do nothing for it.

    That was the diagnosis. If you disagree, you don't go further.

    So allow this uneducated ex-sepherd punk to take for a few minutes of his life the
    responsibility of being a CEO in the Lua universe. I was joking but at the same time
    perhaps is what you are missing. Last time, i took the courage to point to Dirk for
    this role, but we missed him. So speaking as a CEO and with the usual disclaimer:
    I do not write in Lua, my last two years i write in C and i need another eighteen to
    be proficient and i do not know if i catch up in my 53 and with four kids to feed,
    working in the fields, so if i get some things wrong or they are too optimistic, do
    not hesitate to correct. But my mind is going to blow away by staring the posibilities.

    So:
    Around this company :-), there are some of the best living developers in the planet.

    As far it conserns the syntax, i'm thinking of the following changes (some of them
    are only cosmetics and some are enhancements, all of them might be quite intrusive):

      - replace local with var
      - use let for constants
      - use public for explicit global scope
      - split with clear semantics the table type (into array and dictionary types)
      - do not allow syntax ambiguities, possibly introduce by default the semicolon, or
        otherwise you go the Python way and use spaces to denote blocks, but avoid with
        any cost such syntax ambiguity. The code should be easy to parse for the human
        mind and without second thoughts. Speaking generally, nowhere in the code, should
        be spend on syntax thinking thing, only devote this energy to logic
      - introduce a blessed by the community an object oriented style (i know there are
        many people that do not like it, but the fact is that can be very usefull for
        large scale projects, but of course do it the Lua way)
      - use zero-based indexing as everyone in the world does, even if you got it right,
        which you didn't (in my humble opinion)
      - possible use optional static typing like ravi does, which is proved that provides
        performance boost

    If you do that, possible one weak job for a dedicated developer (but lets say at the
    end of this year), then make a big fuss with a short summary, like:

    char promise[] = "I won't break any code again. This product is quite mature.\n"
    "The community ended up on this, and any new code will be compatible from now and "
    "it will be compatible for the next hundred of years.\n"
    "Same promise for the C API.\n"
    "We also incorporated jit technology.\n"
    "It is also capable to compile your code in wasm.\n"
    "With the distribution is bundled a native package manager which built in Rock.\n"
    "The community has already over 2 thousands of packages to choose.\n"
    "For your convenience we offer also a basic standard library, wwhich should be "
    "enough to cover basic expectations, that can be used as starting point.\n"
    "As you might know, We favor flexibility/mechanics and design instead of Policy.\n"
    (thanks Rodrigo)

    #ifdef WE_WORKED_A_LITTLE_BIT_HARDER
    "It is also capable to export/import your code in/from any language you want.\n"
    "It also offers a distribution ready to be used instantly in small devices.\n"
    #endif

    "We benchmark this and proved to be the faster interpreted language.\n"
    "Our bencmarks shows that is quite efficient with memory resources.\n"
    "And because we don't use globals at all, it should work perfectly in \n"
    "multithreads applications.\";

    for (int i = 0; i < zillion_of_times_in_the_biggest_forums; i++)
    fprintf (stdout, "%s\n", promise);

    When you are done with this, then we'll discuss for the next step, which is
    to provide products (community based and with respects to the environment :)).

    If you make any money (for the start you might want to give 1 euro per month
    to be indepented), then do not forget me. If i won't be alive, give them to
    my kids.

    This thread it should die as it deserves, because it speaks about others and
    not for what we can do. If we continue to complain, then it is because we
    like to cry, possible because we didn't have too much attention in our life.

    All the best to you all,
      Αγαθοκλής

    12345 ... 7