Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The evolution of Lua, continued [pdf]

lua.org

Post reply on HN
Print view View original

121–130 of 175 posts

Re: The evolution of Lua, continued [pdf]

#121

Post by bawolff »

hackthemack wrote: post #107
bawolff wrote: post #104

Earlier quoted context omitted.

I like lua better because its minimalist. Javascript feels like a kitchen sink language. Otoh, missing ++, +=, ..= operators really bothers me. But that's just personal taste, not objective by any means.

Yeah. I think if I were to pick one reason, it would be Lua is "minimalist". But, like I wrote, maybe, it too, would have just had lots of stuff added onto it if it had been in the browser. Hard to say. I love ++, but you know what? I was shocked when a co-worker pointed out that it is frowned upon to use ++ in javascript. It some big companies, their linter settings mark ++ as something that should be changed. https…

Lol, i suppose there is no accounting for taste, but the justification for that rule is really something.

Appearently its really confusing if you put a bunch of newlines between the ++ operator and its ophand. No kidding.

Re: The evolution of Lua, continued [pdf]

#122

Post by Rohansi »

kragen wrote: post #46
Rohansi wrote: post #41

Earlier quoted context omitted.

LuaJIT is also stuck at Lua 5.1 (by choice) while the latest is Lua 5.4, with 5.5 on the way.

You say that as if Lua 5.3 and 5.4 were better than Lua 5.2 (which LuaJIT has support for most of the new features of) or 5.1, rather than merely newer. But programming languages don't decay like your teeth.

They don't decay but it results in a split like Python 2 vs. 3 where some Lua code is not valid in applications using LuaJIT.

Re: The evolution of Lua, continued [pdf]

#123

Post by kragen »

Rohansi wrote: post #122
kragen wrote: post #46

Earlier quoted context omitted.

You say that as if Lua 5.3 and 5.4 were better than Lua 5.2 (which LuaJIT has support for most of the new features of) or 5.1, rather than merely newer. But programming languages don't decay like your teeth.

They don't decay but it results in a split like Python 2 vs. 3 where some Lua code is not valid in applications using LuaJIT.

That happens with all Lua applications, because Lua has never aimed for backward compatibility from one version to the next, so applications basically never upgrade to a new version of Lua.

Re: The evolution of Lua, continued [pdf]

#124

Post by b_e_n_t_o_n »

plopz wrote: post #119
b_e_n_t_o_n wrote: post #98

Earlier quoted context omitted.

In practice you don't run into these issues often. I'm annoyed when you see different function declaration conventions in the same codebase, but generally () => is used for either one line functions or inline lambdas, and function foo(){} for everything else. Nobody uses var anymore. The implicit conversions is a definite footgun tho.

Funny you mention nobody uses var anymore when I just saw a post on here yesterday that perf critical code still uses var since it's faster

Bundlers will convert let/const to var, assign classes and functions to var etc but generally people don't write it themselves unless they want to (ab)use its semantics for performance reasons.

Re: The evolution of Lua, continued [pdf]

#125

Post by strenholme »

pansa2 wrote: post #102
hackthemack wrote: post #42

I was thinking a while back, how nice it would be if lua was the scripting language in the browser instead of javascript. There are some projects to compile lua to wasm and have it run in the browser... https://pluto-lang.org/web/#env=lua%3A5.4.6&code=if%20_PVERS... But interoperability with the DOM is the missing key. Still, if lua was used instead of javascript, I could see myself saying... man, I wonder what brows…

IIRC Brendan Eich has talked about this - if he’d adopted Lua in 1995 instead of creating JavaScript, it wouldn’t have been Lua 5.x but Lua 2.x. Lua has improved substantially from version to version because it’s been able to break compatibility. That wouldn’t be possible in the browser, so today we’d still be stuck using (an augmented version of) the outdated Lua 2.x.

Yes, he did:

https://web.archive.org/web/20191024193930/https://twitter.c...

“Lua in 1995 was very different, no coros e.g., and no one would be happy if it flash-froze and then slow-forked on a different path from Lua's. See https://news.ycombinator.com/item?id=1905155 and yes, wasm is the right long-term plan. In 1995 it was supposed to be Java, but that didn't pan out!”

Re: The evolution of Lua, continued [pdf]

#126

Post by Dylan16807 »

realharo wrote: post #72
hackthemack wrote: post #42

I was thinking a while back, how nice it would be if lua was the scripting language in the browser instead of javascript. There are some projects to compile lua to wasm and have it run in the browser... https://pluto-lang.org/web/#env=lua%3A5.4.6&code=if%20_PVERS... But interoperability with the DOM is the missing key. Still, if lua was used instead of javascript, I could see myself saying... man, I wonder what brows…

What specifically do you think would be better? Lua shares many of JS's quirks (like the relationship between arrays and non-array objects, the behavior of undefined for non-existent object properties, metatables are somewhat similar to JS prototypes, etc.) and adds a bunch more (lack of continue statement, 1-indexing, cannot have nil values in tables). I can see people liking or disliking Lua and JS both , depending…

Nil is better than how undefined works. It's not just as bad and then more bad on top.

Re: The evolution of Lua, continued [pdf]

#127

Post by Dylan16807 »

ufo wrote: post #57
strenholme wrote: post #36

Earlier quoted context omitted.

As it turns out, it’s possible with Lua going back to 5.1 to not allow undeclared global variables: https://www.lua.org/pil/14.2.html That code looks like this in Lua 5.1: function set(name, val) rawset(_G, name, val or false) end function exists(name) if rawget(_G, name) then return true end return false end throwError = {__newindex = function(self,name) error("Unknown global " .. name) end, __index = function(self,…

Naturally, the main catch is that this only detects the violation at run-time. It also won't stop you from accidentally overwriting a global variable that already exists.

Do the declarations in 5.5 prevent overwriting? That sounds tricky to define and implement.

Re: The evolution of Lua, continued [pdf]

#128

Post by strenholme »

groovy2shoes wrote: post #66
jrop wrote: post #51

Earlier quoted context omitted.

I always wrote Lua off, scoffing at the 1-based indexing, until I was "forced" to learn it thanks to Neovim. What a delightful little language it is. I do wish I could do certain things less verbosely (lambdas would be nice) -- but then again, I defeat myself by suggesting it, because not having all the features makes Lua so approachable.

Lua has lambdas. They too suffer from verbosity, of course, but they're there. function(x) return x; end

There are patches for this so the above can be expressed with something like this:

  [ (x) | x ]
http://lua-users.org/files/wiki_insecure/power_patches/5.4/l...

And for Lua 5.1:

http://lua-users.org/files/wiki_insecure/power_patches/5.1/l...

(I personally don’t use patches like this because “Lua 5.1” is something pretty standardized with a bunch of different implementations; e.g. I wrote my Lua book with a C# developer who was using the moonsharp Lua implementation)

Re: The evolution of Lua, continued [pdf]

#129

Post by recursivecaveat »

thayne wrote: post #108
rebolek wrote: post #60

Earlier quoted context omitted.

Some people think that writing years as 2025 is wrong because this will lead to problems in year 9999 (y10k bug? I'm not sure if they call it that way) so they decided to introduce leading zero as it would solve something and not just postpone the problem to 99999.

So they are assuming that: - this comment will still be around in 8000 years - we will still be using the same calendar system in 8000 years - people 8000 years in the future will leave off the leading 1 of years for some reason, and will use a leading 0 to disambiguate dates from the previous 10000 year period.

I would say it is a symbolic reminder to care about the long term consequences of our actions. In the same way we have holidays to remind us about the environment or mortality.

Re: The evolution of Lua, continued [pdf]

#130

Post by cycomachead »

realharo wrote: post #72
hackthemack wrote: post #42

I was thinking a while back, how nice it would be if lua was the scripting language in the browser instead of javascript. There are some projects to compile lua to wasm and have it run in the browser... https://pluto-lang.org/web/#env=lua%3A5.4.6&code=if%20_PVERS... But interoperability with the DOM is the missing key. Still, if lua was used instead of javascript, I could see myself saying... man, I wonder what brows…

What specifically do you think would be better? Lua shares many of JS's quirks (like the relationship between arrays and non-array objects, the behavior of undefined for non-existent object properties, metatables are somewhat similar to JS prototypes, etc.) and adds a bunch more (lack of continue statement, 1-indexing, cannot have nil values in tables). I can see people liking or disliking Lua and JS both , depending…

I love JS and Ruby, and I spent a bit of time maintaining a web app in Lua.

There are parts about the language I really enjoy. I like dynamic languages; I don't run into type issues so often it bothers me, but the tooling around Lua still leaves me wishing for me.

Part of this is really my own ability, or lack thereof, but I feel slow and constrained in lua. I have a hard time debugging, but I don't feel these things in other languages.

Post reply on HN