Re: A Look at the Design of Lua

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

Re: A Look at the Design of Lua

Jon Chesterfield
Is there a draft available? I'm curious, but not curious enough to sign up with the ACM.

Cheers

Jon

Date: Fri, 26 Oct 2018 17:38:20 -0200
Subject: A Look at the Design of Lua published in CACM
The paper below appeared today in Communications of the ACM:

A Look at the Design of Lua
Communications of the ACM, November 2018, Vol. 61 No. 11, Pages 114-123
https://cacm.acm.org/magazines/2018/11/232214-a-look-at-the-design-of-lua/abstract
https://doi.org/10.1145/3186277

Reply | Threaded
Open this post in threaded view
|

Re: A Look at the Design of Lua

Andrew Starks-2



On October 27, 2018 at 8:10:12 AM, Jon Chesterfield ([hidden email]) wrote:

Is there a draft available? I'm curious, but not curious enough to sign up with the ACM.

Cheers

Jon

One option is to buy the article for $15 dollars.


-Andrew

Reply | Threaded
Open this post in threaded view
|

Re: A Look at the Design of Lua

Albert Chan
In reply to this post by Jon Chesterfield
Reply | Threaded
Open this post in threaded view
|

Re: A Look at the Design of Lua

Dirk Laurie-2
In reply to this post by Andrew Starks-2
Op Sa., 27 Okt. 2018 om 15:29 het Andrew Starks <[hidden email]> geskryf:

>> Is there a draft available? I'm curious, but not curious enough to sign up with the ACM.

The article is aimed at computer professionals that know no Lua. It
would also be very useful to someone that has been asked to present an
introductory lecture on Lua. It has very little to offer to expert Lua
programmers.

> One option is to buy the article for $15 dollars.

That's $1.50 per three-column page.

Considering that the PiL 4th edition e-book (388 pages) costs less
than double that, I doubt that you will think you got value for your
money.

Reply | Threaded
Open this post in threaded view
|

Re: A Look at the Design of Lua

Alexander Mokrushyn
In reply to this post by Andrew Starks-2
It so cool to see LuaStudio app here https://vimeo.com/292779036 !
Crossed my fingers, it will not crash on this video :)

Alexander M

Reply | Threaded
Open this post in threaded view
|

Re: A Look at the Design of Lua

Luiz Henrique de Figueiredo
In reply to this post by Jon Chesterfield
> Is there a draft available? I'm curious, but not curious enough to sign up with the ACM.

I'm sorry about that. I think the full article in HTML and PDF will be
freely available after a few months.

Reply | Threaded
Open this post in threaded view
|

Re: A Look at the Design of Lua

Andrew Starks-2


On Sat, Oct 27, 2018 at 09:02 Luiz Henrique de Figueiredo <[hidden email]> wrote:
> Is there a draft available? I'm curious, but not curious enough to sign up with the ACM.

I'm sorry about that. I think the full article in HTML and PDF will be
freely available after a few months.


I did purchase it and read it. It is as the title describes: a look at the design of Lua. 

If I have a need to present Lua for consideration in my company, I plan on using it for that purpose.

Andrew
Reply | Threaded
Open this post in threaded view
|

Re: A Look at the Design of Lua

Luiz Henrique de Figueiredo
In reply to this post by Luiz Henrique de Figueiredo
The article now seems to be freely available at
https://cacm.acm.org/magazines/2018/11/232214-a-look-at-the-design-of-lua/fulltext

If that doesn't work for you, try the first CACM link in
http://www.inf.puc-rio.br/%7Eroberto/cvpub.html

Reply | Threaded
Open this post in threaded view
|

Re: A Look at the Design of Lua

Hisham
On Sun, 28 Oct 2018 at 07:38, Luiz Henrique de Figueiredo
<[hidden email]> wrote:
> The article now seems to be freely available at
> https://cacm.acm.org/magazines/2018/11/232214-a-look-at-the-design-of-lua/fulltext

I'm slightly annoyed that basic Lua module examples often display
messy naming practices. Here, the module is written named as "M",
stored in a file called "mymodule" and required into a variable "vec".
I understand that this is to didactically showcase that the names are
not _required_ to be the same, but it promotes those practices (which
are sadly common among Lua programmers, probably due to top-down
examples like this) and IMO it makes the module system look even more
jerry-rigged. The article itself mentions that the module system is
not as elegant as it could be. The naming choices here don't do it any
favors: if everything was named "vec" in that example, programmers
coming from other languages would find it pretty straightforward. And
if the non-messy approach was common practice, I wouldn't have to
explain to coworkers why Lua module names don't match when they are
finding their way through large codebases.

Let people learn that names don't need to match when the day arrives
when they need to resolve an actual naming conflict, instead of
promoting messy naming from day one.

-- Hisham

Reply | Threaded
Open this post in threaded view
|

Re: A Look at the Design of Lua

Dirk Laurie-2
Op Wo., 31 Okt. 2018 om 16:38 het Hisham <[hidden email]> geskryf:

> I'm slightly annoyed that basic Lua module examples often display
> messy naming practices. Here, the module is written named as "M",
> stored in a file called "mymodule" and required into a variable "vec".
> I understand that this is to didactically showcase that the names are
> not _required_ to be the same, but it promotes those practices (which
> are sadly common among Lua programmers, probably due to top-down
> examples like this) and IMO it makes the module system look even more
> jerry-rigged.

I have no problem with what Lua programmers do. In fact local renaming
is to my mind good practice.

local json = require"org.conman.parsers.json"

Nothing wrong with that.

I do have a problem with what some Lua package writers do. The actual
name to be required is something Unixly cryptic like lfs or lom. but
the package name is longer (luafilesystem) and may even have nothing
to do with the module name (luaexpat). BTW why must the package name
start with or contain the tautological "lua"?

Reply | Threaded
Open this post in threaded view
|

Re: A Look at the Design of Lua

Sean Conner
It was thus said that the Great Dirk Laurie once stated:

> Op Wo., 31 Okt. 2018 om 16:38 het Hisham <[hidden email]> geskryf:
>
> > I'm slightly annoyed that basic Lua module examples often display
> > messy naming practices. Here, the module is written named as "M",
> > stored in a file called "mymodule" and required into a variable "vec".
> > I understand that this is to didactically showcase that the names are
> > not _required_ to be the same, but it promotes those practices (which
> > are sadly common among Lua programmers, probably due to top-down
> > examples like this) and IMO it makes the module system look even more
> > jerry-rigged.
>
> I have no problem with what Lua programmers do. In fact local renaming
> is to my mind good practice.

  The package name is "lua-xml".  The file is "LuaXml.lua".  The resulting
module name is "xml".  Annoying as hell.

> local json = require"org.conman.parsers.json"
>
> Nothing wrong with that.

  No.  But there, the package name is 'org.connman.parsers.json'.  The file
is 'org/conman/parsers/json.lua'.  And the resulting module is named ...
well, in this case, it would be a local variable named 'json'.  There's a
logical progression one can follow.

> I do have a problem with what some Lua package writers do. The actual
> name to be required is something Unixly cryptic like lfs or lom. but
> the package name is longer (luafilesystem) and may even have nothing
> to do with the module name (luaexpat). BTW why must the package name
> start with or contain the tautological "lua"?

  Because otherwise someone might mistake it for JavaScript.

  -spc


Reply | Threaded
Open this post in threaded view
|

Re: A Look at the Design of Lua

Thijs Schreijer


On 31 Oct 2018, at 21:40, Sean Conner <[hidden email]> wrote:

It was thus said that the Great Dirk Laurie once stated:
Op Wo., 31 Okt. 2018 om 16:38 het Hisham <[hidden email]> geskryf:

I'm slightly annoyed that basic Lua module examples often display
messy naming practices. Here, the module is written named as "M",
stored in a file called "mymodule" and required into a variable "vec".
I understand that this is to didactically showcase that the names are
not _required_ to be the same, but it promotes those practices (which
are sadly common among Lua programmers, probably due to top-down
examples like this) and IMO it makes the module system look even more
jerry-rigged.

I have no problem with what Lua programmers do. In fact local renaming
is to my mind good practice.

 The package name is "lua-xml".  The file is "LuaXml.lua".  The resulting
module name is "xml".  Annoying as hell.

local json = require"org.conman.parsers.json"

Nothing wrong with that.

 No.  But there, the package name is 'org.connman.parsers.json'.  The file
is 'org/conman/parsers/json.lua'.  And the resulting module is named ...
well, in this case, it would be a local variable named 'json'.  There's a
logical progression one can follow.

I do have a problem with what some Lua package writers do. The actual
name to be required is something Unixly cryptic like lfs or lom. but
the package name is longer (luafilesystem) and may even have nothing
to do with the module name (luaexpat). BTW why must the package name
start with or contain the tautological "lua"?

 Because otherwise someone might mistake it for JavaScript.

That’s why I name modules and packages the same way, yet in the repo I add a `.lua`.


> luarocks install binaryheap

$ local binaryheap = require “binaryheap”

So far it has been very clean (unfortunately my older stuff doesn’t follow this convention)

Thijs

Reply | Threaded
Open this post in threaded view
|

Re: A Look at the Design of Lua

Luiz Henrique de Figueiredo
In reply to this post by Luiz Henrique de Figueiredo
The article seems to be freely available at
https://cacm.acm.org/magazines/2018/11/232214-a-look-at-the-design-of-lua/fulltext

Does anyone have a problem reading the full article at that URL?

hz
Reply | Threaded
Open this post in threaded view
|

Re: A Look at the Design of Lua

hz
Reading fine.

Thanks.

> 在 2018年11月2日,上午4:28,Luiz Henrique de Figueiredo <[hidden email]> 写道:
>
> The article seems to be freely available at
> https://cacm.acm.org/magazines/2018/11/232214-a-look-at-the-design-of-lua/fulltext
>
> Does anyone have a problem reading the full article at that URL?
>


Reply | Threaded
Open this post in threaded view
|

Re: A Look at the Design of Lua

Pierre Chapuis
In reply to this post by Hisham
On Wed, Oct 31, 2018, at 15:37, Hisham wrote:

> I'm slightly annoyed that basic Lua module examples often display
> messy naming practices. Here, the module is written named as "M",
> stored in a file called "mymodule" and required into a variable "vec".

For what it's worth, I like the "M" part. It's even part of the internal style
guide at my company. It makes modules easier to rename for one thing.
Also works when you overload existing libraries (e.g. you define
`mycompany.json` that depends on luajson...).

The file being named "mymodule" is a bit weird outside of an example
but like Dirk said we frequently do require something called "xxx.foo"
as "foo". That's not unique to Lua either, for instance Python has the
`import xxx as yyy` syntax to do the same thing.

I also agree with Dirk that the main issue is the name of the LuaRocks
package, not the name of the file. Often with large modules the file
name will be `init.lua` anyway.

--
Pierre Chapuis