Thought experiment: what would you remove from Lua

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

Re: Thought experiment: what would you remove from Lua

Marc Balmer


> Am 01.08.2018 um 00:16 schrieb Dibyendu Majumdar <[hidden email]>:
>
> Are there features in Lua that could be removed to create a simpler language?

Obviously, syntactic sugars could be removed, as they do not add to the power of the language.

>
> Of course 'simpler' needs to be defined.
>
> Simpler for users?
> Simpler for implementors?

Exactly.  Removing aforementioned syntactic sugars would make the code a bit harder to read, and less maintainable, imo.
>
> Often these are conflicting goals.
>
> I, for instance, never use co-routines ... and I know they add a bunch
> of complexity both from implementation and user point of view.
>
> Another feature I never use is inheritance - at most I use simple class objects.

Lua has no inheritance.

In general, I would probably not remove anything and not add much.  But then, nobody asks me and I am not in charge ;)

>
> Regards
> Dibyendu
>


Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Peter Hickman-3
The only things I would want to add to Lua is "trailing conditionals" (I think they are called)

if process_the_data == true then
  slice_and_dice(data)
end

would become

slice_and_dice(data) if process_the_data == true

It really reads smoother for me like this (and having 'unless' would make things readable too)

I don't use Lua as much as Ruby or Python but when I do I find the the Lua code can be quite verbose for trivial parts. I keep having to stop and ask "what is this bunch of syntax doing" The phrase 'intent revealing' comes to mind, Lua can be quite nuts and bolts and syntax can obscure semantics. When reading code what it is doing is more important that how it is doing it, at least on the first pass

However I use Lua for what it is. Never thought "if only ..."

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Axel Kittenberger
== true ...

I'll always cringe to that since beginners think an if _must_ have a comparison operator in it.

It is already boolean, no need to thest it again.

if process_the_data then
  slice_and_dice(data)
end

PS: Exception is when it explicitly checks it to be a boolean value at the same time, so 1 ought to be false..

Oh and this discussion is about removing not adding.

On Thu, Aug 2, 2018 at 2:53 PM, Peter Hickman <[hidden email]> wrote:
The only things I would want to add to Lua is "trailing conditionals" (I think they are called)

if process_the_data == true then
  slice_and_dice(data)
end

would become

slice_and_dice(data) if process_the_data == true

It really reads smoother for me like this (and having 'unless' would make things readable too)

I don't use Lua as much as Ruby or Python but when I do I find the the Lua code can be quite verbose for trivial parts. I keep having to stop and ask "what is this bunch of syntax doing" The phrase 'intent revealing' comes to mind, Lua can be quite nuts and bolts and syntax can obscure semantics. When reading code what it is doing is more important that how it is doing it, at least on the first pass

However I use Lua for what it is. Never thought "if only ..."


Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Oliver Kroth
What about

return process_the_data and slice_and_dice( data )

?


Am 02.08.2018 um 15:00 schrieb Axel Kittenberger:
slice_and_dice(data) if process_the_data == true

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Peter Hickman-3
In reply to this post by Axel Kittenberger
On 2 August 2018 at 14:00, Axel Kittenberger <[hidden email]> wrote:
== true ...

I'll always cringe to that since beginners think an if _must_ have a comparison operator in it.

It is already boolean, no need to thest it again.

if process_the_data then
  slice_and_dice(data)
end


Better safe than sorry. process_the_data might return anything, anything other than false or nil will resolve as true. I prefer to avoid 'sort of true' in conditionals
 
Oh and this discussion is about removing not adding.

Oops my bad. Got sidetracked when Mark Balmer mentioned readability.

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Peter Hickman-3
In reply to this post by Oliver Kroth
On 2 August 2018 at 15:23, Oliver Kroth <[hidden email]> wrote:
What about

return process_the_data and slice_and_dice( data )

?

Thanks, will try and remember that
 
Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Tom Sutcliffe
In reply to this post by Axel Kittenberger
> On 31 Jul 2018, at 11:16 pm, Dibyendu Majumdar <[hidden email]> wrote:
>
> Are there features in Lua that could be removed to create a simpler language?

Interesting question.

> On 1 Aug 2018, at 8:03 am, Axel Kittenberger <[hidden email]> wrote:
>
> dibyendu> Are there features in Lua that could be removed to create a simpler language?
>
> - the .. operator and with it implicit string/number coercions.
> - goto, the only sensible applications IMO can be replaced with better: continue and a more sophisticated try/except/throw scheme than pcall.
>
> As a rule of thumb I'd say, if it's a feature that's not found in most other programming languages in similar areas and it's controversial, it was probably not that good of an idea. However, if it's a feature that distinguishes Lua from other programming languages and there is a wider consensus about it, it probably was one of the better ideas (for example the : operator vs. JS 'this' shenanigans, or metatables in general etc.).

I think that's a good summary.

I haven't personally found a use for gotos in Lua, but I'm sure they are useful when translating code from another language which has them (or in machine-generated code), so I don't really object to them as they never get in my way. I just don't use them.

The only thing that I'd really get rid of is the implicit string/number conversions. Those you *do* unavoidably hit just by using numbers and strings and occasionally not realising there's a wrong type somewhere. I'd much prefer less magic and more "you've done something wrong here" errors. Javascript's handling of type coercions is insane, C++ is pretty close, basically implicit type conversions are almost always a slippery slope of unpleasantness. lua_tolstring being able to mutate the underlying value and mess up lua_next (amongst other things) is one of those gotchas that just shouldn't exist, and is (imo) one of the few genuine missteps in the Lua C API. KISS is the only way to go here which keeps your sanity intact.

I think I've pretty much used every other aspect of Lua in a significant way, by which I mean there's a real-world project relying on it. coroutines, debug, utf8, userdata, most metamethods, bitwise operators, ability to build for severely resource-constrained platforms with a compiler that doesn't even support floating point, I've used them all. Maybe weak tables? I don't think I've yet relied on them although I've come close a few times, so I don't think I'd be happy if they weren't an option. string.reverse I admit I've never ever used, although the 'cost' to the language of having it is so minimal I don't really care, and it's interesting to see that some people have found a use for it. Lua's string pattern matching you can prise from my cold, dead hands given how much simpler and smaller it is to regex (while being still pretty powerful) and how it's actually built in (yes std C++, I'm looking at you).

Lua is pretty much the definition of everything I really need in a language, and nothing that I don't. Which is one of the reasons I like it :-)

Cheers,

Tom


Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Dirk Laurie-2
Op Do., 6 Sep. 2018 om 19:34 het Tom Sutcliffe <[hidden email]> geskryf:

> The only thing that I'd really get rid of is the implicit string/number conversions.

Well, it's already in Lua 5.3 as simple compiling with NOCVTS2N, and
in Lua 5.4 you don't need to recompile, just assign nil to the
offending string metamethods.

> Lua is pretty much the definition of everything I really need in a language, and nothing that I don't. Which is one of the reasons I like it :-)

Amen, brother.

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Axel Kittenberger
In reply to this post by Tom Sutcliffe
Maybe weak tables?

Oh I use them in Lua! Usecase, opaque handlers given to a user script, which the weak table links to the full implementation in the "core". Once the user script drops them, the core can cleanup the linked objects too.

And I'm looking forward to the day Javascript finally gets something similar (WeakMap/WeakSet is only half of it). I'd really want to intern immutable objects by hash values which is not yet possible.

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Petri Häkkinen
In reply to this post by Dibyendu Majumdar

> On 1 Aug 2018, at 1.16, Dibyendu Majumdar <[hidden email]> wrote:
>
> Are there features in Lua that could be removed to create a simpler language?

I would remove ’:’ and ’self’. I never use them in my code and they support bad habits.

Petri
Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Tom Sutcliffe
In reply to this post by Dirk Laurie-2
On 6 Sep 2018, at 9:18 pm, Dirk Laurie <[hidden email]> wrote:
>
> Op Do., 6 Sep. 2018 om 19:34 het Tom Sutcliffe <[hidden email]> geskryf:
>
>> The only thing that I'd really get rid of is the implicit string/number conversions.
>
> Well, it's already in Lua 5.3 as simple compiling with NOCVTS2N, and
> in Lua 5.4 you don't need to recompile, just assign nil to the
> offending string metamethods.

I didn't realise that LUA_NOCVTN2S disabled the lua_tolstring automatic conversions (I thought it controlled just the Lua-side ones like "a"..1). Now that I look, it does indeed. I've learnt something today!

Now I'm really kicking myself for not enabling those in my last project, maybe I can quietly sneak them in with enough testing of all the existing code... (I was trying to be as close to stock Lua as possible, at the time, but it has progressed to the point where I probably could safely change this).

Cheers,

Tom
Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Sean Conner
In reply to this post by Petri Häkkinen
It was thus said that the Great Petri Häkkinen once stated:
>
> > On 1 Aug 2018, at 1.16, Dibyendu Majumdar <[hidden email]> wrote:
> >
> > Are there features in Lua that could be removed to create a simpler language?
>
> I would remove ’:’ and ’self’. I never use them in my code and they support bad habits.

  What bad habbits?  The excessive use of OOP?

  -spc


Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Sam Pagenkopf
In reply to this post by Tom Sutcliffe
It would break everything, but I'd remove the top-level function keyword entirely, with the side effects. 2 more keystrokes for `=` in free functions, plus 4 for `self` in methods.

It's really not so bad. It's more visible. You need to write ``x = function (self, ...)`` in some places no matter what. It would become more clear that function declarations in lua are just assignments. It's also less to parse, and one less thing for new users to trip on. I did attempt the nonsensical ``x:y = function (...)`` when I was first learning! When I write lua now, I prefer to write ``x.y = function (self, ...)`` for everything that uses a self, because I want to be very clear whether its a free function or a method (prefer free functions!). I don't know if it would warrant removing the `x:y(args)` call syntax, I'm okay with a shorthand if the behavior is consistent, and the ``self`` is just repeated text which was passed anonymously to begin with. Speaking of, the ``x:y{key: value, ...}`` call is a delicious and useful shorthand for named method args.

I'm also reasonably sure that you could convert any valid lua program using the top-level function keyword into a valid one with the other syntax. Correct me if I'm wrong on that, edge cases are always fun.

On Thu, Sep 6, 2018 at 12:35 PM Tom Sutcliffe <[hidden email]> wrote:
> On 31 Jul 2018, at 11:16 pm, Dibyendu Majumdar <[hidden email]> wrote:
>
> Are there features in Lua that could be removed to create a simpler language?

Interesting question.

> On 1 Aug 2018, at 8:03 am, Axel Kittenberger <[hidden email]> wrote:
>
> dibyendu> Are there features in Lua that could be removed to create a simpler language?
>
> - the .. operator and with it implicit string/number coercions.
> - goto, the only sensible applications IMO can be replaced with better: continue and a more sophisticated try/except/throw scheme than pcall.
>
> As a rule of thumb I'd say, if it's a feature that's not found in most other programming languages in similar areas and it's controversial, it was probably not that good of an idea. However, if it's a feature that distinguishes Lua from other programming languages and there is a wider consensus about it, it probably was one of the better ideas (for example the : operator vs. JS 'this' shenanigans, or metatables in general etc.).

I think that's a good summary.

I haven't personally found a use for gotos in Lua, but I'm sure they are useful when translating code from another language which has them (or in machine-generated code), so I don't really object to them as they never get in my way. I just don't use them.

The only thing that I'd really get rid of is the implicit string/number conversions. Those you *do* unavoidably hit just by using numbers and strings and occasionally not realising there's a wrong type somewhere. I'd much prefer less magic and more "you've done something wrong here" errors. Javascript's handling of type coercions is insane, C++ is pretty close, basically implicit type conversions are almost always a slippery slope of unpleasantness. lua_tolstring being able to mutate the underlying value and mess up lua_next (amongst other things) is one of those gotchas that just shouldn't exist, and is (imo) one of the few genuine missteps in the Lua C API. KISS is the only way to go here which keeps your sanity intact.

I think I've pretty much used every other aspect of Lua in a significant way, by which I mean there's a real-world project relying on it. coroutines, debug, utf8, userdata, most metamethods, bitwise operators, ability to build for severely resource-constrained platforms with a compiler that doesn't even support floating point, I've used them all. Maybe weak tables? I don't think I've yet relied on them although I've come close a few times, so I don't think I'd be happy if they weren't an option. string.reverse I admit I've never ever used, although the 'cost' to the language of having it is so minimal I don't really care, and it's interesting to see that some people have found a use for it. Lua's string pattern matching you can prise from my cold, dead hands given how much simpler and smaller it is to regex (while being still pretty powerful) and how it's actually built in (yes std C++, I'm looking at you).

Lua is pretty much the definition of everything I really need in a language, and nothing that I don't. Which is one of the reasons I like it :-)

Cheers,

Tom


Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Axel Kittenberger
It would break everything, but I'd remove the top-level function keyword entirely, with the side effects. 2 more keystrokes for `=` in free functions, plus 4 for `self` in methods.

The issue is with recursive functions. You can't do that simply with the "name = function()" syntax.
Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Dirk Laurie-2
In reply to this post by Sam Pagenkopf
Op Sa., 8 Sep. 2018 om 06:24 het Sam Pagenkopf <[hidden email]> geskryf:

> It would break everything, but I'd remove the top-level function keyword entirely, with the side effects. 2 more keystrokes for `=` in free functions, plus 4 for `self` in methods.

I never use 'self', but I am not a party OOPer. [1]

In its defence, though:

    'self' is not a keyword.

It is in the same category as 'arg': a pre-assigned non-global
variable with a conventional meaning,

> It would become more clear that function declarations in lua are just assignments.

This is "dieting", i.e. deliberately cutting out sugar. Cutting out
"pairs" and "ipairs" is similar.

Nothing more annoying than having to adjust one's eating habits just
because someone else is dieting, unless you happen to be Saint Paul. I
prefer not to use 'self' and 'pairs', but I would not dream of
removing them from Lua.

On the other hand, unlike Dibyendu and Paige, writing and supporting
dialects of Lua is not my hobby. (Btw Dibyendu, if you need a name for
this stripped-down Lua of yours, how about Deimos? For over 100 years,
it was the smallest known moon in the universe.)

> When I write lua now, I prefer to write ``x.y = function (self, ...)`` for everything that uses a self, because I want to be very clear whether its a free function or a method (prefer free functions!).

This is what I do, except I don't use the word self, I use a name that
tells me what class I expect. If the metatable is called "Deque", the
first parameter in its methods is "deque".

> I don't know if it would warrant removing the `x:y(args)` call syntax,

It won't. That syntax does not need 'self'.

The question I ask is: is the logic of the program easier to follow?
And the one feature of object-oriented programming that I do still
embrace (admittedly only in a platonic way) is that there is at most
one value passed to a method that you are allowed to change. Moving
that value out of the argument list makes a lot of sense.

This syntax comes into its own when 'x' is an expression. Youl'll find
some people saying you should anyway assign that expression to a local
variable, but I do find e.g.

   for k,v in next,template do
      tbl[k]:action(v)
   end

a useful idiom.

-- Dirk

[1] My love affair with "object-oriented" languages like Delphi and
C++ (note that these are about as old as Lua) was never more than a
passing crush; I did not even get past Paragraph 1 of tutorials for
Ada and Java, and I don't know more about Smalltalk than its name.

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Dirk Laurie-2
In reply to this post by Axel Kittenberger
Op Sa., 8 Sep. 2018 om 07:26 het Axel Kittenberger <[hidden email]> geskryf:

>> It would break everything, but I'd remove the top-level function keyword entirely, with the side effects. 2 more keystrokes for `=` in free functions, plus 4 for `self` in methods.
>
> The issue is with recursive functions. You can't do that simply with the "name = function()" syntax.

Oh, you can. "local function func(...)"  is syntactic sugar for

local func
func = function(...)

I'm sure this is in the manual, but don't have it open in my browser right now.

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Italo Maia
I would probably remove/change global by default; all the rest is quite handy.

Em sáb, 8 de set de 2018 08:32, Dirk Laurie <[hidden email]> escreveu:
Op Sa., 8 Sep. 2018 om 07:26 het Axel Kittenberger <[hidden email]> geskryf:

>> It would break everything, but I'd remove the top-level function keyword entirely, with the side effects. 2 more keystrokes for `=` in free functions, plus 4 for `self` in methods.
>
> The issue is with recursive functions. You can't do that simply with the "name = function()" syntax.

Oh, you can. "local function func(...)"  is syntactic sugar for

local func
func = function(...)

I'm sure this is in the manual, but don't have it open in my browser right now.

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Dibyendu Majumdar
In reply to this post by Dirk Laurie-2
On Sat, 8 Sep 2018 at 06:27, Dirk Laurie <[hidden email]> wrote:
> On the other hand, unlike Dibyendu and Paige, writing and supporting
> dialects of Lua is not my hobby. (Btw Dibyendu, if you need a name for
> this stripped-down Lua of yours, how about Deimos? For over 100 years,
> it was the smallest known moon in the universe.)
>

Nice name. I think there is a smaller language / implementation
lurking inside Lua that might be more efficient and optimizable. The
problem as always is of compatibility - and the fact that it is very
very hard to establish a new language. It requires full time attention
and many years of effort. The amount of time I am able to give to Ravi
for example, is insufficient to do this. And the difficulty then of
popularizing it makes it hard to be motivated.

Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Dirk Laurie-2
Op Sa., 8 Sep. 2018 om 14:33 het Dibyendu Majumdar
<[hidden email]> geskryf:

>
> On Sat, 8 Sep 2018 at 06:27, Dirk Laurie <[hidden email]> wrote:
> > On the other hand, unlike Dibyendu and Paige, writing and supporting
> > dialects of Lua is not my hobby. (Btw Dibyendu, if you need a name for
> > this stripped-down Lua of yours, how about Deimos? For over 100 years,
> > it was the smallest known moon in the universe.)
> >
>
> Nice name. I think there is a smaller language / implementation
> lurking inside Lua that might be more efficient and optimizable. The
> problem as always is of compatibility - and the fact that it is very
> very hard to establish a new language. It requires full time attention
> and many years of effort. The amount of time I am able to give to Ravi
> for example, is insufficient to do this. And the difficulty then of
> popularizing it makes it hard to be motivated.

Actually Lua is so minimalistic, the question is always what one could
add rather than what could one remove, and the answer in both cases
can usually be implemented by loading a package.

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Francisco Olarte
In reply to this post by Sam Pagenkopf
Hi:

On Sat, Sep 8, 2018 at 6:24 AM, Sam Pagenkopf <[hidden email]> wrote:
> It would break everything, but I'd remove the top-level function keyword
> entirely, with the side effects. 2 more keystrokes for `=` in free
> functions, plus 4 for `self` in methods.
....
> I'm also reasonably sure that you could convert any valid lua program using
> the top-level function keyword into a valid one with the other syntax.
> Correct me if I'm wrong on that, edge cases are always fun.

Well, if I read correctly (5.3 ref manual, 3.4.11 function definitions
) all "top level" function keyword usages are syntactic sugar with a
translation defined there, so it's easy to be sure. You could remove
it, but normally it is called syntactic sugar instead of
syntactic-PITA for a reason.

F.O.S.

12345