[mildly OT] Some info about Python

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

Re: [mildly OT] Some info about Python

Michal Kottman-2
On Mon, Feb 3, 2020, 12:38 AM Archie Cobbs <[hidden email]> wrote:
That means:
...
- It configures and builds with autoconf

Let me ignore all the other stuff and respond to this with https://giphy.com/gifs/8vUEXZA2me7vnuUvrs (TL;DW: "No").
Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Roberto Ierusalimschy
In reply to this post by Oliver Schmidt
> What's IMHO missing is a central appropriate place where Lua community
> collaboration leads together. This place should be:
> [...]
>
> What we currently have is:
>
> [...]
>
> 3) Luarocks: as I wrote: in my opinion this is the best thing we currently have:
> it also has a rating system but this seems only half implemented: one can give
> stars but these are not visible in search results. Discussions and quality
> control are also missing, e.g. it is not possible to detect for what platform
> packages are available etc. There are also major problems that are unsolved,
> AFAIK, see for example:
> http://lua.2524044.n2.nabble.com/Non-uniqueness-of-module-names-tp7686140.html

Why don't we all rally behind Luarocks and try to fix those drawbacks?

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Enrico Colombini
On 03-Feb-20 14:49, Roberto Ierusalimschy wrote:
> Why don't we all rally behind Luarocks and try to fix those drawbacks?

Not a bad idea, but I'd like to point out (as others have done) that
binary installation on Windows must be painless (read: click-and-go) for
non-programmers that just want to run and possibly modify Lua applications.

Also, many programmers are not willing to install a C compiler on
Windows and to spend hours or days to make it all work, especially when
Python installs just fine (well, almost, but there is Anaconda
Distribution for advanced users).

--
   Enrico

Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Coda Highland


On Mon, Feb 3, 2020 at 10:56 AM Enrico Colombini <[hidden email]> wrote:
On 03-Feb-20 14:49, Roberto Ierusalimschy wrote:
> Why don't we all rally behind Luarocks and try to fix those drawbacks?

Not a bad idea, but I'd like to point out (as others have done) that
binary installation on Windows must be painless (read: click-and-go) for
non-programmers that just want to run and possibly modify Lua applications.

Non-programmers shouldn't even be expected to install Lua, much less LuaRocks. Applications on Windows are expected to ship their own dependencies. This calls for a packager, and these already exist.

If you instead mean people who aren't experienced programmers that find themselves with a need to work with Lua code regardless, we have to consider the use case. I would imagine that the majority of the time they're going to be working with Lua embedded into another application, which makes binary distributions of anything generic less helpful. 
 
Also, many programmers are not willing to install a C compiler on
Windows and to spend hours or days to make it all work, especially when
Python installs just fine (well, almost, but there is Anaconda
Distribution for advanced users).

It should be pretty straightforward for a LuaRocks Windows distribution to include a C compiler that's already configured appropriately. This shouldn't be considered an obstacle.

/s/ Adam
Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Enrico Colombini
On 03-Feb-20 18:04, Coda Highland wrote:
> Non-programmers shouldn't even be expected to install Lua, much less
> LuaRocks. Applications on Windows are expected to ship their own
> dependencies. This calls for a packager, and these already exist.
>
> If you instead mean people who aren't experienced programmers that find
> themselves with a need to work with Lua code regardless, we have to
> consider the use case. I would imagine that the majority of the time
> they're going to be working with Lua embedded into another application,
> which makes binary distributions of anything generic less helpful.

I was also thinking of hobbysts / tinkerers, that make a non-trivial
percentage of python users, perhaps on the way to become professional
programmers. They run some script and they just want to change a line or
two.

Also, with the couple of Lua-based open-source applications I published
I found out that most Windows users have trouble even setting a path and
writing things correctly on a command line. So, the easiest, the better.

I think Python is successful despite its shortcomings because, apart
from the bandwagon effect:
- It can be installed and used immediately. If you need a module, you
just import it.
- It is mostly used as Basic-like glue language between libraries.
Most users do not install Python because they consider it an interesting
language, but because they want to use (e.g.) OpenCV, or do some very
simple scripting, or to set up a mini-server for some testing, without
having to read more than a few lines of documentation.
Very few users choose a language for its intrinsic value.

>     Also, many programmers are not willing to install a C compiler on
>     Windows and to spend hours or days to make it all work, especially when
>     Python installs just fine (well, almost, but there is Anaconda
>     Distribution for advanced users).
>
> It should be pretty straightforward for a LuaRocks Windows distribution
> to include a C compiler that's already configured appropriately. This
> shouldn't be considered an obstacle.

It shouldn't, but I suspect it could not be as easy as it sounds. I'll
be glad to be proven wrong.

--
   Enrico

Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Coda Highland
On Mon, Feb 3, 2020 at 11:27 AM Enrico Colombini <[hidden email]> wrote:
I was also thinking of hobbysts / tinkerers, that make a non-trivial
percentage of python users, perhaps on the way to become professional
programmers. They run some script and they just want to change a line or
two.

Even experienced developers benefit from having an easily installed development environment. We had some of these in the past but they've kinda fallen unmaintained. If we're going to move forward with a project like this, I think that a Lua+LuaRocks distribution in the same vein as LuaForWindows is a good idea.
 
Also, with the couple of Lua-based open-source applications I published
I found out that most Windows users have trouble even setting a path and
writing things correctly on a command line. So, the easiest, the better.

I am of the opinion that this is a lost cause. Publishing applications should be done with a packager, and this is true regardless of platform. You're not going to solve this problem for non-technical Windows users no matter how easy it is.
 
I think Python is successful despite its shortcomings because, apart
from the bandwagon effect:
- It can be installed and used immediately. If you need a module, you
just import it.

Has Python gotten better at this or something? Last time I tried it I had a real headache getting Python installed on Windows in a way that wasn't a headache to use for anything but launching IDLE from the start menu.

Python isn't immune to the problem, either; if you go outside of the standard libraries, you still need pip to pull in dependencies and cross your fingers that there's a binary build that'll work on Windows.

On that note: Promoting a beginner-friendly Lua IDE, even if it's not suitable for professional use, is going to be the biggest step we could take towards making it easy for novices to get started with Lua development on Windows.
 
> It should be pretty straightforward for a LuaRocks Windows distribution
> to include a C compiler that's already configured appropriately. This
> shouldn't be considered an obstacle.

It shouldn't, but I suspect it could not be as easy as it sounds. I'll
be glad to be proven wrong.

The part that's hard isn't including the compiler; it's ensuring ABI compatibility with external libraries. This more or less means that binary distributions are mandatory for anything where you can't just build the entire dependency chain. The solution is going to require module authors with compiled dependencies to go out of their way to ensure Windows compatibility.

/s/ Adam
Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Eduardo Ochs
In my way of seeing things making a package manager that makes developers super-happy (1) is a pre-requisite for (2) having a distribution for all OSs including Windows that beginners find easy to use. And (1) can be done in 100 or 200 programmer-hours with expertise that we already have, while (2) needs 10000000000 hours at least, plus black-belt social skills, lots of money to hire external people, and luck.
  Just my 2c =),
     Eduardo Ochs

On Mon, 3 Feb 2020, 14:52 Coda Highland, <[hidden email]> wrote:
On Mon, Feb 3, 2020 at 11:27 AM Enrico Colombini <[hidden email]> wrote:
I was also thinking of hobbysts / tinkerers, that make a non-trivial
percentage of python users, perhaps on the way to become professional
programmers. They run some script and they just want to change a line or
two.

Even experienced developers benefit from having an easily installed development environment. We had some of these in the past but they've kinda fallen unmaintained. If we're going to move forward with a project like this, I think that a Lua+LuaRocks distribution in the same vein as LuaForWindows is a good idea.
 
Also, with the couple of Lua-based open-source applications I published
I found out that most Windows users have trouble even setting a path and
writing things correctly on a command line. So, the easiest, the better.

I am of the opinion that this is a lost cause. Publishing applications should be done with a packager, and this is true regardless of platform. You're not going to solve this problem for non-technical Windows users no matter how easy it is.
 
I think Python is successful despite its shortcomings because, apart
from the bandwagon effect:
- It can be installed and used immediately. If you need a module, you
just import it.

Has Python gotten better at this or something? Last time I tried it I had a real headache getting Python installed on Windows in a way that wasn't a headache to use for anything but launching IDLE from the start menu.

Python isn't immune to the problem, either; if you go outside of the standard libraries, you still need pip to pull in dependencies and cross your fingers that there's a binary build that'll work on Windows.

On that note: Promoting a beginner-friendly Lua IDE, even if it's not suitable for professional use, is going to be the biggest step we could take towards making it easy for novices to get started with Lua development on Windows.
 
> It should be pretty straightforward for a LuaRocks Windows distribution
> to include a C compiler that's already configured appropriately. This
> shouldn't be considered an obstacle.

It shouldn't, but I suspect it could not be as easy as it sounds. I'll
be glad to be proven wrong.

The part that's hard isn't including the compiler; it's ensuring ABI compatibility with external libraries. This more or less means that binary distributions are mandatory for anything where you can't just build the entire dependency chain. The solution is going to require module authors with compiled dependencies to go out of their way to ensure Windows compatibility.

/s/ Adam
Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Michal Kottman-2
In reply to this post by Enrico Colombini
On Mon, Feb 3, 2020, 6:27 PM Enrico Colombini <[hidden email]> wrote:
I think Python is successful despite its shortcomings because, apart
from the bandwagon effect:
- It can be installed and used immediately. If you need a module, you
just import it.

I wonder why nobody mentioned LuaDist yet? Go to http://luadist.org/, download a lua+bootstrap zip for your platform (Linux, Mac, Windows), extract somewhere, boom, you have Lua plus a large selection of libraries: https://pastebin.com/WNDXux9W

Everything is "portable", in the sense that Lua interpreter and the libraries are self contained in the folder, and can be moved elsewhere (including a USB stick).

Not satisfied with the selection of libraries in the ready-to-download "dist"? Use bundled bin/luadist  or bin/luarocks to install more packages. You can even create your own distribution! All available packages are in https://github.com/LuaDist/Repository

Everything is already on Github for those wanting to contribute.
Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Paul K-2
> Promoting a beginner-friendly Lua IDE, even if it's not suitable for professional use, is going to be the biggest step we could take towards making it easy for novices to get started with Lua development on Windows.

I may be biased in my assessment, but I did run several semester-long
classes for high school students that were new to Lua and programming
in general using ZeroBrane Studio IDE and none of them had problems
using it in class or on their own. It's also mentioned on the Getting
Started page (https://www.lua.org/start.html).

> I wonder why nobody mentioned LuaDist yet? Go to http://luadist.org/, download a lua+bootstrap zip for your platform (Linux, Mac, Windows), extract somewhere, boom, you have Lua plus a large selection of libraries: https://pastebin.com/WNDXux9W

I second this. I looked at integrating LuaDist or LuaRocks with
ZeroBrane Studio 6 years ago and picked LuaDist for two reasons: it
provides binary distributions (although it also supports building from
source) and it can be integrated using git, lfs, and luasocket
libraries (some other pros and cons are listed here:
http://notebook.kulchenko.com/zerobrane/lua-package-managers-luadist-luarocks-and-integration-with-zerobrane-studio).
One can run `luadist.install('penlight')` command from ZeroBrane
Studio (assuming LuaDist package is already installed, which is just a
lua file) and get penlight library installed and available for use.
This also works for any other library in LuaDist repo.

There are definitely limitations to what LuaDist does, but those are
primarily related to modules not being refreshed and binaries not
updated for Lua 5.3.

Paul.

Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Oliver Schmidt
In reply to this post by Enrico Colombini
On 03.02.20 17:55, Enrico Colombini wrote:
> On 03-Feb-20 14:49, Roberto Ierusalimschy wrote:
>> Why don't we all rally behind Luarocks and try to fix those drawbacks?

Yes why? Perhaps too much fun doing other things with the Lua programming language.

>From the big picture view there are two areas where improvements to Luarocks
could be made:

- luarocks website -

Extending collaboration features, tagging and ranking system of projects etc.
For example, currently it is even not possible to contact a rockspec uploader if
the uploader is not the author mentioned in the homepage.

A good and very popular example that can serve as inspiration for improvements
could be the AUR (Arch User Repository): https://aur.archlinux.org/

Here every user can upload package builds (=rockspecs). Each package build has
its own git repository where the history of the package build can be seen. The
upstream sources are separated from the package builds. Packages can be flagged
as outdated or orphaned or can be requested to be remove. Orphaned packages can
be taken over by other users. For each package there is a discussion area about
problems and so on with this package build.


-luarocks tool - see below

> Not a bad idea, but I'd like to point out (as others have done) that binary
> installation on Windows must be painless (read: click-and-go) for
> non-programmers that just want to run and possibly modify Lua applications.
> Also, many programmers are not willing to install a C compiler on Windows and to

Regarding the Luarocks tool I would love to see a cleaner separation of
different layers. Currently Luarocks is providing solutions for different use
cases in an all-in-one solution:

1.) On the lower end it is a description language about what is contained in a
module and how this is has to be assembled to become Lua packages (at least with
the builtin build type).

2.) On the higher end it's also possible to have binary rocks which looks like
Luarocks being a binary distribution.

IMHO it would be good to have these things separated. The higher layer could be
build on top of the lower layer.

There is also not one "higher layer" that would make everyone happy: The higher
layer could also conflict with other binary distributions: each Linux
distribution has its own package management. For Mac there is for example brew
package manager. For Windows there is for example MSYS2. But nothing speaks
against generating a binary Lua distribution out of the lower layer. (For
windows I personally would use MSYS2 as build system and to build a binary
distribution using this, but other people might prefer other toolsets).

For the lower layer things would be easier if there was only the builtin build
type, i.e. only the possibility to specify sources and compiler/linker flags.
With this most modules could be build. Complexer builds would remain external
dependencies.

The builtin build type could be improved. The good thing is: this can currently
be done independently of Luarocks without breaking backward compatibility by
providing external build types, see for example:
https://github.com/osch/luarocks-build-extended#luarocks-build-extended

Perhaps reducing the functionality of luarocks tool to a simple lower layer
would reduce the overall popularity of Luarocks :-( One the other hand, it would
be Lua-like to have a core as simple as possible and to build complexer things
on top of it.

Best regargs,
Oliver

Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Enrico Colombini
In reply to this post by Coda Highland
On 03-Feb-20 18:51, Coda Highland wrote:
> On that note: Promoting a beginner-friendly Lua IDE, even if it's not
> suitable for professional use, is going to be the biggest step we could
> take towards making it easy for novices to get started with Lua
> development on Windows.

Perhaps, but Python hasn't got one out of the box and is much used
anyway. An IDE could be an interesting step after standard libraries,
distribution and package manager (not necessarily in this order).

I now digress, but simple, easy to use graphics and/or an UI builder
could really made a language popular. But that would be a long distance
down the road and certainly not worth dispersing energy now.

--
   Enrico

Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Enrico Colombini
In reply to this post by Eduardo Ochs
On 03-Feb-20 19:29, Eduardo Ochs wrote:
> In my way of seeing things making a package manager that makes
> developers super-happy (1) is a pre-requisite for (2) having a
> distribution for all OSs including Windows that beginners find easy to
> use. And (1) can be done in 100 or 200 programmer-hours with expertise
> that we already have, while (2) needs 10000000000 hours at least, plus
> black-belt social skills, lots of money to hire external people, and luck.
>    Just my 2c =),
>       Eduardo Ochs

I think your estimate for (1) is perhaps a bit optimistic but, sadly, I
share your feeling on (2). It would be a major task.

--
   Enrico

Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Sean Conner
In reply to this post by Oliver Schmidt
It was thus said that the Great Oliver once stated:
>
> Extending collaboration features, tagging and ranking system of projects etc.
> For example, currently it is even not possible to contact a rockspec uploader if
> the uploader is not the author mentioned in the homepage.

  The description.maintainer field is supposed to contain contact
information about the rockspec maintainer.

  -spc


Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Sean Conner
In reply to this post by Enrico Colombini
It was thus said that the Great Enrico Colombini once stated:
>
> Also, with the couple of Lua-based open-source applications I published
> I found out that most Windows users have trouble even setting a path and
> writing things correctly on a command line. So, the easiest, the better.

  I was about to rant about this mindset---the constant drive to make
computers "easier" and "more intuitive" to use to the point where they
become useless for their intended jobs.  I mean, a *car* is conceptually
eaiser to use than a computer and we still train people to drive.  Hell,
when rotary phones first came out people had to be trained in their use, but
we forgot that kids learned how to use them by watching their parents (so
yes, even kids needed "training" to use a phone).

  But then I recalled one system at work that *no one* wants to deal with.
The interface, a command line interface, is *so* arcane it makes the Unix
command line seem friendlier.  Everybody at the company is kind of hoping it
just fades away (and it is.  Slowly.  Perhaps in another twenty years) so we
don't have to deal with it.

  I then remembered programming in BASIC as a kid, where I would have to
deal with code that looked like:

        0 'CODE TAKEN FROM THE RAINBOW M
        AGAZINE, VOL. IV, NO. 1 (AUGUST
        1984), PAGE 78-'SOPWITH COCO' FL
        IES AGAIN!
        1700 X=30+SIN(JB)*28:Y=160-COS(J
        B)*28:CIRCLE(FA,FB),1,0:CIRCLE(X
        ,Y),1,1:FA=X:FB=Y:RETURN
        1710 IF D7=10 AND N(S)=0 THEN RE
        TURN ELSE LINE(30,160)-(SX,SY),P
        RESET:DRAW"C0;BM83,170;XA$(D7);B
        M-10,0;XA$(D6);BM-7,0;XA$(D5);C1
        ;XA$(10);BM+7,0;XA$(10);BM+10,0;
        XA$(10);":LINE(128,40)-(IX,IY),P
        RESET:CIRCLE(162,92+GX),1,0,.1:D
        7=10:D6=10:D5=10
        1712 IF AZ<AL THEN AZ=0
        1730 SCREEN1,0:RETURN
        1740 F=INT(RB(S)*.5729):G=INT(RB
        (S)*5.729)-(10*F):I=INT(RB(S)*57
        .29)-(100*F)-(10*G):DRAW"C0;BM66
        ,151;XA$(FS);BM+7,0;XA$(GS);BM+7
        ,0;XA$(IS);C1;XA$(I);BM-7,0;XA$(
        G);BM-7,0;XA$(F);":FS=F:GS=G:IS=
        I:JB=RB(S):GOTO 1700

(the limits of 32K RAM and a 32 column screen).  I even went on (again, as
a kid) to learn assembly langauge (for multiple machines even!).

  But in all of this, it comes down to self-interest.  Making things easier
is nice, certainly.  But until a person has *a reason* to care, they won't.
I had a reason to learn BASIC (my computer was useless without programs) and
assembly (I read that assembly language programmers got paid more, and
programs written in it were was faster than those in BASIC) and I put up
with ... let's say "less than optimum" interfaces (32 x 16 text screen is
quite limited).

  Then there's the whole herd mentality I see in programming.  Heaven forbid
you use some obscure tech as it limits your career (but on the flip side,
you now have to compete with a bazillion other programmers who use the same
tech---it cuts both ways).  I haven't found it limiting personally (I used
assembly for way too long, then C.  My preferred computers were often the
less popular machines, or in the case of college, way too expensive) and I
feel I'm way more productive in Lua than the other members on my team (who
still use C and C++).  But too many people want to move with the herd as
it's the "safer" choice.

  What does this mean for Lua?  I don't know.  The trends I do see is that
the more opinionated a tool set is (Go---there's only one way to format the
code; Python---there's only one way to to things) the more popular (because
programmers don't have to think.  The more batteries are available, the less
code that has to be written, the less a programmer has to think, the better.
The more popular a language is, the less chance of being fired over using
it, the better (no one ever got fired for buying IBM, or Microsoft).

  So alternatively, a language has to be useful, but not require thinking
and very popular.  Kind of explains JavaScript in a way ...

  -spc (Thining of bowing out of the whole batteries thang for Lua---it's
        just not worth the effort because of laziness on the part of
        everybody else ... )

Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Sean Conner
In reply to this post by Oliver Schmidt
It was thus said that the Great Oliver once stated:
>
> 3) Luarocks: as I wrote: in my opinion this is the best thing we currently have:
> it also has a rating system but this seems only half implemented: one can give
> stars but these are not visible in search results. Discussions and quality
> control are also missing, e.g. it is not possible to detect for what platform
> packages are available etc. There are also major problems that are unsolved,
> AFAIK, see for example:
> http://lua.2524044.n2.nabble.com/Non-uniqueness-of-module-names-tp7686140.html

  In my opinion, the only way this will be solved will be for Hisham to
unilaterally declare "a Lua module name MUST be ..." and enforce it through
LuaRocks or for Roberto to declare "a Lua mdoule name MUST be ..." and
enforce it through Lua.  Anything else will just devolve into useless
conversation.  Because we've *had* this conversation.  Repeatedly.  Several
times.  Again.  And again.

  -spc


Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Coda Highland
In reply to this post by Enrico Colombini
On Mon, Feb 3, 2020 at 4:27 PM Enrico Colombini <[hidden email]> wrote:
On 03-Feb-20 18:51, Coda Highland wrote:
> On that note: Promoting a beginner-friendly Lua IDE, even if it's not
> suitable for professional use, is going to be the biggest step we could
> take towards making it easy for novices to get started with Lua
> development on Windows.

Perhaps, but Python hasn't got one out of the box and is much used
anyway. An IDE could be an interesting step after standard libraries,
distribution and package manager (not necessarily in this order).

Yes it does? Python on Windows has shipped with IDLE for a VERY long time.
 
/s/ Adam
Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Enrico Colombini
On 04-Feb-20 01:03, Coda Highland wrote:

> On Mon, Feb 3, 2020 at 4:27 PM Enrico Colombini <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On 03-Feb-20 18:51, Coda Highland wrote:
>      > On that note: Promoting a beginner-friendly Lua IDE, even if it's
>     not
>      > suitable for professional use, is going to be the biggest step we
>     could
>      > take towards making it easy for novices to get started with Lua
>      > development on Windows.
>
>     Perhaps, but Python hasn't got one out of the box and is much used
>     anyway. An IDE could be an interesting step after standard libraries,
>     distribution and package manager (not necessarily in this order).
>
>
> Yes it does? Python on Windows has shipped with IDLE for a VERY long time.

I have to confess I didn't know, probably because I never saw anyone
using it. It could be due to my limited sample: industrial programmers
and students / hobbysts / 'makers'.

Anyway, I still think 'a step at a time' would be the best policy. First
step a stable, 'blessed' library.

Then there is the matter of stability: Lua getting better is a great
thing but, on the other hand, it is hard to build a large user base on
shifting foundations. An industrial client of mine still develops in
Python 2.7 because splitting the codebase would be a huge headache for
re-testing and maintenance of machinery installed around the world.

But supporting multiple Lua versions for each module could be hard work
(and no, I don't see a simple solution to this dilemma).

--
   Enrico

Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Enrico Colombini
In reply to this post by Sean Conner
On 04-Feb-20 00:46, Sean Conner wrote:

>    I then remembered programming in BASIC as a kid, where I would have to
> deal with code that looked like:
>
> 0 'CODE TAKEN FROM THE RAINBOW M
> AGAZINE, VOL. IV, NO. 1 (AUGUST
> 1984), PAGE 78-'SOPWITH COCO' FL
> IES AGAIN!
> 1700 X=30+SIN(JB)*28:Y=160-COS(J
> B)*28:CIRCLE(FA,FB),1,0:CIRCLE(X
> ,Y),1,1:FA=X:FB=Y:RETURN
>  [snip]
>
> (the limits of 32K RAM and a 32 column screen).  I even went on (again, as
> a kid) to learn assembly langauge (for multiple machines even!).

Fond memories :-)
(I actually started with RPN on HP calculators, then pencil-assembling
and hand-typing hex code on a KIM-1, then learned BASIC. Yes, I'm a
dinosaur)
>    What does this mean for Lua?  I don't know.  The trends I do see is that
> the more opinionated a tool set is (Go---there's only one way to format the
> code; Python---there's only one way to to things) the more popular (because
> programmers don't have to think.  The more batteries are available, the less
> code that has to be written, the less a programmer has to think, the better.
> The more popular a language is, the less chance of being fired over using
> it, the better (no one ever got fired for buying IBM, or Microsoft).

I think you are right. It could be down to limited time, limited
attention span, desire/need to see results immediately, lower
concentration required, plain laziness...
Not the world I'd prefer if I had a choice, but it is the one we live in.

Basically, the larger the user space you wish for, the dumbest (in a
broad sense) the language and its environment have to be, at least on
the surface.

>    So alternatively, a language has to be useful, but not require thinking
> and very popular.  Kind of explains JavaScript in a way ...

Well, Javascript lives in a different environment where it could do
worse, especially in the latest version. On the other hand, most Web
programmers write trivial code but use opaque libraries / frameworks
they have no control over.

>    -spc (Thining of bowing out of the whole batteries thang for Lua---it's
> just not worth the effort because of laziness on the part of
> everybody else ... )

Uh... your honor, I plead guilty here.
That's one of the reasons I think a small-steps policy would be easier
to pursue.

--
   Enrico

Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Peter Drahoš
In reply to this post by Paul K-2


On Feb 3, 2020, at 7:55 PM, Paul K <[hidden email]> wrote:

There are definitely limitations to what LuaDist does, but those are
primarily related to modules not being refreshed and binaries not
updated for Lua 5.3.

If there is still any interest in LuaDist[1] I do have an unpublished development version with the following feature set:

* Can download and automatically use LuaRocks based modules of certain build types
* Uses Conan[2] package manager instead of LuaRocks and legacy LuaDist
* This means I can have indexed, searchable modules cache in Atrifactory[3]
* It can download and cache binary modules for multiple platforms, architectures and compilers
* It can quickly integrate with existing C/C++ libraries[4]
* It can consume the generated packages and modules in C/C++ applications with minimum effort
* Feature compatible with current LuaDist but no “luadist” Lua module yet
* This variant still supports LuaDist based single directory deployments of all binaries and modules as Michal Kottman mentioned.
* However it can also compile all modules as static library. It is trivial to embed entire module libraries as source/bytecode in applications.
* Also supports embedded bare metal static builds without filesystems
* Is still Windows/Linux/macOS compatible and can use almost any modern compiler
* Supports Lua 5.1 - 5.4 and LuaJIT

This approach has much lower maintenance than the original LuaDist. It is mostly in sync with compatible LuaRocks modules automatically. Modules that require more effort to be portable because of complex dependencies can rely on Conan packaged C/C++ libraries. The entire thing can even manage cross-compilation by using Conan profiles.

pd

[3] https://jfrog.com/artifactory/ (community version)

Reply | Threaded
Open this post in threaded view
|

Re: [mildly OT] Some info about Python

Fernando Jefferson-2
In reply to this post by Enrico Colombini

Enrico:

I miss using RPN (Reverse Polish Notation) on my HP29C, (please see photo) with 32 memories (16 of them continuous, 16 volatile), 100 programming steps ...

All this in the past millennium ...

If you think you are a dinosaur for this, what would I be, starting to program on the Intel 8008 in 1973?

 

Em 2020-02-04 07:58, Enrico Colombini escreveu:

On 04-Feb-20 00:46, Sean Conner wrote:
   I then remembered programming in BASIC as a kid, where I would have to
deal with code that looked like:

    0 'CODE TAKEN FROM THE RAINBOW M
    AGAZINE, VOL. IV, NO. 1 (AUGUST
    1984), PAGE 78-'SOPWITH COCO' FL
    IES AGAIN!
    1700 X=30+SIN(JB)*28:Y=160-COS(J
    B)*28:CIRCLE(FA,FB),1,0:CIRCLE(X
    ,Y),1,1:FA=X:FB=Y:RETURN
 [snip]

(the limits of 32K RAM and a 32 column screen).  I even went on (again, as
a kid) to learn assembly langauge (for multiple machines even!).

Fond memories :-)
(I actually started with RPN on HP calculators, then pencil-assembling and hand-typing hex code on a KIM-1, then learned BASIC. Yes, I'm a dinosaur)
   What does this mean for Lua?  I don't know.  The trends I do see is that
the more opinionated a tool set is (Go---there's only one way to format the
code; Python---there's only one way to to things) the more popular (because
programmers don't have to think.  The more batteries are available, the less
code that has to be written, the less a programmer has to think, the better.
The more popular a language is, the less chance of being fired over using
it, the better (no one ever got fired for buying IBM, or Microsoft).

I think you are right. It could be down to limited time, limited attention span, desire/need to see results immediately, lower concentration required, plain laziness...
Not the world I'd prefer if I had a choice, but it is the one we live in.

Basically, the larger the user space you wish for, the dumbest (in a broad sense) the language and its environment have to be, at least on the surface.

   So alternatively, a language has to be useful, but not require thinking
and very popular.  Kind of explains JavaScript in a way ...

Well, Javascript lives in a different environment where it could do worse, especially in the latest version. On the other hand, most Web programmers write trivial code but use opaque libraries / frameworks they have no control over.

   -spc (Thining of bowing out of the whole batteries thang for Lua---it's
    just not worth the effort because of laziness on the part of
    everybody else ... )

Uh... your honor, I plead guilty here.
That's one of the reasons I think a small-steps policy would be easier to pursue.

 

--
Fernando Jefferson
CCE-PUC-Rio - Professor
Projeto UpLua - Coordenador
Cel: +5521-99763-2135
1234567