Breakthrough dream

classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Breakthrough dream

Pierre Chapuis
March 25, 2017 3:27 PM, "Peter Aronoff" <[hidden email]> wrote:

> Rodrigo Azevedo <[hidden email]> wrote:
>
>> This is not an exclusion, but C libraries are harder to maintain than "Pure
>> Lua".
>
> I’m going to sound like a broken record, but really? Why? I’ve never
> thought of it as being the case—again from experience with other languages.
>
> What I have seen is that *any* library in a language’s stdlib often ends up
> being maintained more slowly, and less well, than non-stdlib equivalents.

Those two statements are not incompatible.

I agree about standard libraries. I have said the same thing at the Workshop
in 2013 and I state by it: a lot of things don't belong in a standard library.

However I do believe pure Lua libraries are easier to maintain than C
libraries, for several reasons:

- They are more portable. Lua is relatively straightforward, whereas
  C standards are underspecified and C code written for one OS with
  a specific compiler typically does not work on others, except if
  a lot of care is take. This is the case for the Lua interpreter,
  which is why writing code in Lua is a good recipe for portability.

- There are more Lua programmers who know Lua than Lua programmers
  who know C. Every dynamic language should expect higher contribution
  in pure libraries than in C libraries. It is the case for Python,
  Ruby, etc as well.

- It is easier to write Lua code that works well in all of Lua's
  different ecosystems (PUC Lua embedded or not, LuaJIT,
  OpenResty, etc) than C code. For instance, libraries built on
  top of LuaSocket are reusable in OpenResty and they will be
  non-blocking, because OpenResty has re-implemented a compatible
  socket API. It would not be the case of C modules.

- The Lua language is slightly more stable across Lua versions
  than the Lua C API.

--
Pierre Chapuis

Reply | Threaded
Open this post in threaded view
|

Re: Breakthrough dream

Dirk Laurie-2
2017-03-27 10:56 GMT+02:00 Pierre Chapuis <[hidden email]>:
> March 25, 2017 3:27 PM, "Peter Aronoff" <[hidden email]> wrote:

> - The Lua language is slightly more stable across Lua versions
>   than the Lua C API.

My 5.2 modules only needed recompiling. The API changes are mostly
non-breaking, like routines now returning an integer where previously
they returned a void. But I'n sure the combined ingenuity of this list can
dream up a 5.2 module that breaks under 5.3 :-(

Reply | Threaded
Open this post in threaded view
|

Re: Breakthrough dream

Andrew Starks-2
In reply to this post by Rodrigo Azevedo
On Sat, Mar 25, 2017 at 8:04 AM, Rodrigo Azevedo <[hidden email]> wrote:

> Based on the thread 'Selenophobia', and your major experience, choose 5
> characteristics you think indispensable to keep Lua advancing as a
> "general-purpose script language";
>
> 1) an expanded basic library (some batteries), well organized, maintained
> and documented. "Pure Lua" libraries at least.
> 2) easy installation on major operating systems (with shared libraries)
> 3) threads (pthreads!? not Lua's coroutine)
> 4) optional type annotations (performance, error check etc)
> 5) easy, transparent, way to port libraries to new versions of Lua.
>
> Is this possible to start, organize and support for a long period ( a
> 'larger' community)?
>
> Or Lua's community is so specialized, and happy, like the 'webdevs' of
> stackoverflow, that this is not possible in a foreseen future?
>
> and consequently the 'general-purpose script language' is an utopic,
> romantic, dream.
>
>
> --
> Rodrigo Azevedo Moreira da Silva

Taking the informal pulse of this list as presented to me by my own
memory, I would write this list in this way...

# Sandboxing is hard.

Whenever someone talks about sandboxing, this is the response that
they get. Lua is already constructed in a way that aides sandboxing.
Could more be done?

# Concurrency, especially between Lua States?

Again, Lua is fantastic for concurrency. Also, Lua is designed to
seamlessly integrate into any system environment, which means that any
deep-level concurrency support would be counterproductive to many
applications for Lua.

However, could more be done to speed up or aide in the marshaling of
native Lua values between threads? Specifically interned strings and
table structures? Maybe work on the new garbage collector might
provide an opportunity for some new mechanism.

# Lua as a general language? / How can Lua be more popular?

This issue is raised over and over again and probably will be forever,
until two things happen:

1. A new problem is solved by a new development / runtime environment.
2. That project uses a custom flavor of Lua and a set of well
documented, beautifully engineered libraries that enforce well
considered design limitations/opinions, while still respecting Lua's
unique style.

Until a compelling problem is solved with Lua (or Lua-esque) in that
space and in a way that makes people stop and try it out, there will
be no traction, even if Team Lua adds a bunch of standard libraries,
switches to 0 based arrays and adds ++ and -- operators. Since Lua's
primary use case is as a C library for embedding into system
languages, I believe that the most likely path is for someone else to
extend Lua and create a separate ecosystem with enforced design rules
for OOP, functional programming, etc.

Something like Luvit + Moonscript + killer app... or something.

--
Andrew Starks

Reply | Threaded
Open this post in threaded view
|

Re: Breakthrough dream

Dirk Laurie-2
2017-03-27 17:23 GMT+02:00 Andrew Starks <[hidden email]>:

> # How can Lua be more popular?

Frankly, my dear, I don't give a damn.

Reply | Threaded
Open this post in threaded view
|

Re: Breakthrough dream

Philipp Janda
In reply to this post by Pierre Chapuis
Am 27.03.2017 um 10:46 schröbte Pierre Chapuis:
>
> Lua is already pretty easy to install everywhere except on
> Windows. Because I/O is not standard today, a lot of modules
> have C parts so I don't think a Lua development setup without
> a C compiler is realistic. There are plenty of solutions that
> are not so complicated (MinGW + luawinmulti, the Linux
> subsystem, msys2...) but maybe we need something that installs
> a local mingw + Lua + LuaRocks with a graphical installer to
> satisfy some category of users.

Been there, done that[1]. The problem is neither Lua, nor LuaRocks, or
the C compiler or graphical installer. The problem is always the
dependencies. LuaDist was a nice idea, but the Lua community is probably
just not big enough for such an approach. The only way I can see is some
form of binary distribution of dependencies. I experimented with NuGet
and Win-Builds, but Windows is just a demanding development environment.
Maybe things get better with Microsoft's new runtime library strategy ...


Philipp

   [1]: https://github.com/siffiejoe/prg-lr4win



Reply | Threaded
Open this post in threaded view
|

Re: Breakthrough dream

Ross Berteig
In reply to this post by Enrico Colombini


On 3/27/2017 1:52 AM, Enrico Colombini wrote:
> ....
>
> Or simply precompiled DLLs, assuming this is still possible on current
> Windows systems.
>
That was the strength of Lua for Windows. It provided pre-compiled DLLs
and Lua.exe that were all built with the same compiler, C runtime, and
so forth. The important bit was not so much the C modules being
pre-compiled, but that the libraries they wrapped were supplied also
compiled with the same toolchain and C runtime. The handy all-in-one
standard installer worked well on a range of versions of Windows (and
still works on Win 10!).

This made it easy for me to confidently build hardware test fixtures in
Lua, and know that I could document how to get them working at my
customer's site without much hassle beyond "install LfW, now use this
script". The inclusion of IUP (and friends) meant that even GUI tools
were easy to put together.

The big hassle was (and will always be, for Windows) the choice of C
runtime. VS2005's runtime was a pragmatic choice at the time. Being able
to build all of the supporting libraries with VS2005 was necessary. And
of course every useful wrapped library had its own, usually quirky,
build system. Some very useful libraries are surprisingly difficult to
build from source, so the service of providing pre-built binaries with
consistent naming of the Lua core and C runtime DLLs really was quite
valuable.

--
Ross Berteig                               [hidden email]
Cheshire Engineering Corp.           http://www.CheshireEng.com/
+1 626 303 1602


Reply | Threaded
Open this post in threaded view
|

Re: Breakthrough dream or Selenophobia

Russell Haley
In reply to this post by Frank Kastenholz-2
Sorry for the top post. (and most likely the wrong stream of this conversation). Some thoughts on this and prior posts:

Lua showing up on any top ten list is actually a compliment to its wide and varied usage. Hardly what I would call a niche language. I'm sure there are dozens of lanuage communities that would love to be a top ten dreaded language. Perhaps what is meant instead of niche is strength or feature?‎ Likewise, the diversity of variants is a testament to the utility and flexibility of the syntax. 

Lua as it stands (IMHO) is a beautiful, thoughtful piece of work and an amazing piece of technology when taken as a whole. ‎Not a single complaint is 'I can't do x' but simply 'I don't like how I have to do x'.  

I've found multiple threading libraries though I don't look for cross platform compatibility. Also, if one wants a nice IDE and ZeroBrane doesn't have enough features, there is a great add-in for JetBrains IDEA. 

It's always easier to criticize then invent. I am grateful for the ‎fantastic language given away with such a liberal license. The creators are teachers and to ask them to also give away the PIL is to ask them to give away their income.  The meager $30 investment towards the carreer of said complainants on SO would go a long way to alleviate the pains they may have. 

And finally I think the community has done a wonderful job filling in the functional gaps that have been intentionally left to keep the language small and portable. I would say to complainants if they were on my team, "Didn't find the library you like? Oh, well I thought you were a developer? All the sources are available including the LuaRocks website. STFU and fix it yourself. Otherwise don't let the door hit you on the way out." 

Russ

P.s. Counting from zero is stupid. Zero means the absence of units. To co-opt it to mean anything else is to intentionally skew it's meaning. :P

Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.


  Original Message  
From: Frank Kastenholz
Sent: Sunday, March 26, 2017 7:51 AM
To: [hidden email]
Reply To: [hidden email]
Subject: Re: Breakthrough dream

On 3/25/17 3:54 PM, Egor Skriptunoff wrote:

> On Sat, Mar 25, 2017 at 10:26 PM, Dirk Laurie wrote:
>
> 2017-03-25 15:04 GMT+02:00 Rodrigo Azevedo:
>
> > Based on the thread 'Selenophobia', and your major experience, choose 5
> > characteristics you think indispensable to keep Lua advancing as a
> > "general-purpose script language";
> >
> > 1) an expanded basic library (some batteries), well organized, maintained
> > and documented. "Pure Lua" libraries at least.
> > 2) easy installation on major operating systems (with shared libraries)
> > 3) threads (pthreads!? not Lua's coroutine)
> > 4) optional type annotations (performance, error check etc)
> > 5) easy, transparent, way to port libraries to new versions of Lua.
> >
> > Is this possible to start, organize and support for a long period ( a
> > 'larger' community)?
>
> This does sound a bit like someone who wishes to enlarge the listening
> public of a radio station that broadcasts classical music, and comes
> with suggestions like:
>
> * breezy disc jockeys
> * short, snappy pieces instead of those interminable symphonies
> * phone-in discussion programmes
> * jazz is fine music too, isn't it?
>
>
> The analogy with classical music is very incorrect.
> All 5 characteristics being discussed here wouldbe useful for all Lua users.
> They are not contradictory to set of features we already have in the
> language.


These particular changes _could_ be problematic. The project I was on
developed an application environment, with apps coded in Lua, that runs
on a variety of platforms -- different processors and operating systems
and varying levels of resources. On some systems we had 250MHz
cpu speeds, <10MB RAM for our part of the system, and the OS was not
Windows or a flavor of Unix. Anything that would expand the footprint
of the core PUC-Rio Lua (larger libraries, type checking in the
compiler, etc) would be a problem. Similarly, anything that ties Lua
to a specific OS (or family) would be very bad.

That said,

1) What would be reasonable would be to make these sorts of
features truly optional, selectable by #defines in something
like "lua_features.h". I would not want to have to go through
all the source code unwinding things to pull out some features.

2) Despite what this list would like, Lua will never replace, or even
come close to equating, Python or sh or ... as scripting languages.
The others are too embedded in the world's mindset. Lua's
real strength is that it can easily be installed in some other
program, giving that program scripting/config/etc-ability. That is
its market niche. I would _strongly_ urge that the PUC-Rio folks
never risk losing that niche as the consider new functions/features
to add.

Frank Kastenholz









Reply | Threaded
Open this post in threaded view
|

Re: Breakthrough dream or Selenophobia

Ulrich Schmidt
Am 29.03.2017 um 21:31 schrieb Russell Haley:

> Sorry for the top post. (and most likely the wrong stream of this conversation). Some thoughts on this and prior posts:
>
> Lua showing up on any top ten list is actually a compliment to its wide and varied usage. Hardly what I would call a niche language. I'm sure there are dozens of lanuage communities that would love to be a top ten dreaded language. Perhaps what is meant instead of niche is strength or feature?‎ Likewise, the diversity of variants is a testament to the utility and flexibility of the syntax.
>
> Lua as it stands (IMHO) is a beautiful, thoughtful piece of work and an amazing piece of technology when taken as a whole. ‎Not a single complaint is 'I can't do x' but simply 'I don't like how I have to do x'.
>
> I've found multiple threading libraries though I don't look for cross platform compatibility. Also, if one wants a nice IDE and ZeroBrane doesn't have enough features, there is a great add-in for JetBrains IDEA.
>
> It's always easier to criticize then invent. I am grateful for the ‎fantastic language given away with such a liberal license. The creators are teachers and to ask them to also give away the PIL is to ask them to give away their income.  The meager $30 investment towards the carreer of said complainants on SO would go a long way to alleviate the pains they may have.
>
> And finally I think the community has done a wonderful job filling in the functional gaps that have been intentionally left to keep the language small and portable. I would say to complainants if they were on my team, "Didn't find the library you like? Oh, well I thought you were a developer? All the sources are available including the LuaRocks website. STFU and fix it yourself. Otherwise don't let the door hit you on the way out."
>
> Russ

A big +1 :)

The language design is what i ever looked for: easy to lern, you can
code easy/simple programs very quickly and when your skill improves, it
seems the language grows with you and allows all high level stuff like
oop and more.

The Trouble on windows is not lua language related. From my point of
view it is c-compiler related. you have to choose from cygwin, msys,
tdm-gcc, VS2005, VS2005+x, VS2005+y, VS2005+z, ... What a mess!

After using (and registering) a older VS version some years ago i lost
my registration key and cant even reregister or download this verion
anymore and so i stepped away from VS.

For me TDM-gcc works great and with iup and wxlua i have gui libs i can
use.

And Windows is not Windows. You have 32bit and 64bit, 95, vista, 7, 8,
and now 10.

So what compiler/editor/... should someone choose, who wants to build a
lua-studio sufficient for all relevant Windows versions and suitable
for all windows users and all programming tasks? I dont know it and
probably noone knows it.

Ulrich

Reply | Threaded
Open this post in threaded view
|

Re: Breakthrough dream or Selenophobia

Dirk Laurie-2
In reply to this post by Russell Haley
2017-03-29 21:31 GMT+02:00 Russell Haley <[hidden email]>:

> Lua showing up on any top ten list is actually a compliment to its
> wide and varied usage. Hardly what I would call a niche language.
> I'm sure there are dozens of lanuage communities that would love
> to be a top ten dreaded language. Perhaps what is meant instead
> of niche is strength or feature?‎ Likewise, the diversity of variants is
> a testament to the utility and flexibility of the syntax.

I think the reason why Lua is a dreaded language is that those
who develop software in it — that's us — delight in making our
tricks obscure. I consider myself an experienced Lua programmer
by now, and I dread having to modify a program that someone
else wrote.

1. Modules

At the top of a program you see

   local pkg = assert(require "obscuremodule")

The author of the program knows the API for that module. The reader
does not. Does the author document any of that API? Of course not.
It's documented, if at all, inside the module. However, if that "require"
goes through, "pkg" could be any Lua value, any global variable may
have been set, any system library may have been monkey-patched.
The reader has to discern which.

2. Objects

There are any number of object paradigms floating around. Is the
constructor the callable metatable? Is __index distinct from the
metatable. Does the author document any of that? Seldom.

3. Metatables

That one word says all. You know what you do with them. Does
anybody else know?

Reply | Threaded
Open this post in threaded view
|

Re: Breakthrough dream or Selenophobia

Peter Aronoff
Dirk Laurie <[hidden email]> wrote:
> I consider myself an experienced Lua programmer by now, and I dread
> having to modify a program that someone else wrote.

If this is right, it's awfully depressing. It suggests that Lua is (has
become?) one of those "write-only" languages that you hear so much about.

> 1. Modules
>
> At the top of a program you see
>
>    local pkg = assert(require "obscuremodule")
>
> The author of the program knows the API for that module. The reader
> does not. Does the author document any of that API? Of course not.
> It's documented, if at all, inside the module. However, if that "require"
> goes through, "pkg" could be any Lua value, any global variable may
> have been set, any system library may have been monkey-patched.
> The reader has to discern which.

I'm not quite sure what you're upset about here. In my experience (in any
language), the documentation for an imported module is not found in the
code that imports it, it's found in the module itself. In this regard,
I find Lua modules to be on par with Ruby modules in terms of
documentation. That is, documentation for modules is found either (1) in
a formal set of documentation shipped with the module (this is nicest) or
(2) online, usually on the README of the module's repo. Some Ruby modules
provide no docs, just code. I avoid those for all the obvious reasons.
Ditto for Lua.

> 2. Objects
>
> There are any number of object paradigms floating around. Is the
> constructor the callable metatable? Is __index distinct from the
> metatable. Does the author document any of that? Seldom.

This is absolutely true. It's part of the price you pay for trying to have
something that the language itself doesn't provide (and thus standardize).
But in this regard, Lua is no worse than, say, Perl. If you use OOP in
Perl, someone picking up your code usually[1] has to go to whatever code
you require from CPAN to see how _that_ specific OOP works. (I suppose that
things in Perl are better because so many people use Moose. But a new
programmer must still learn Moose in addition to Perl.) Partly for this
reason, I avoid using OOP in Perl and Lua. (I know many people won't like
that solution.  Just saying.)

> 3. Metatables
>
> That one word says all. You know what you do with them. Does
> anybody else know?

Again, I agree here. And, again, as a result, I avoid writing or
using code with metatable magic. Again, many people won't like this
solution.

In replying, I've mostly convinced myself that you're right. How sad.

P

[1]: I'm assuming that nobody uses "raw" or built-in Perl OOP since I don't
     think I've ever run across it in the wild, though lots of Perl coders
     claim that it's just great.

--
We have not been faced with the need to satisfy someone else's
requirements, and for this freedom we are grateful.
    Dennis Ritchie and Ken Thompson, The UNIX Time-Sharing System

Reply | Threaded
Open this post in threaded view
|

Re: Breakthrough dream or Selenophobia

Viacheslav Usov
In reply to this post by Ulrich Schmidt
On Thu, Mar 30, 2017 at 11:33 AM, Ulrich Schmidt <[hidden email]> wrote:

> So what compiler/editor/... should someone choose, who wants to build a lua-studio sufficient for all relevant Windows versions and suitable for all windows users and all programming tasks?

You can download VS Community Edition 2017, it is free (at least for personal/open source use). Choose the Windows XP SDK/toolset. With that, you would be fine supporting versions of Windows from more than 15 years ago till today.

Cheers,
V.
Reply | Threaded
Open this post in threaded view
|

Re: Breakthrough dream or Selenophobia

Luiz Henrique de Figueiredo
In reply to this post by Dirk Laurie-2
>    local pkg = assert(require "obscuremodule")

Calling assert here does nothing because require raises errors if they occur.

Perhaps you mean

        local ok, pkg = pcall(require,"obscuremodule")

Reply | Threaded
Open this post in threaded view
|

Re: Breakthrough dream or Selenophobia

Dirk Laurie-2
2017-03-30 14:18 GMT+02:00 Luiz Henrique de Figueiredo <[hidden email]>:
>>    local pkg = assert(require "obscuremodule")
>
> Calling assert here does nothing because require raises errors if they occur.
>
> Perhaps you mean
>
>         local ok, pkg = pcall(require,"obscuremodule")

Thank you. :-)

12