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

91–100 of 175 posts

Re: The evolution of Lua, continued [pdf]

#91

Post by ecshafer »

munificent wrote: post #84
ecshafer wrote: post #8

It is interesting that so many of the largest languages were developed in a couple year time frame in the early-mid 90s. Python, Javascript, Java, Lua, R. All of these were developed 91-95 and make a bulk of development today.

It is an interesting observation! I'm sure there are a few unrelated factors going on to influence that plus some inadvertent cherry-picking. But I do think there is a thing to the observation too. If I had to make a guess, I'd point to a combination of: 1. This was right around the time that computers were fast enough to afford the runtime cost of garbage collection while still delivering usable apps. The GC languag…

After mulling it over a bit, plus seeing a few other response (Php, Ruby, etc) I think the internet is the reason.

C, C++, Ada, Basic, Fortran. Those were written assuming they were going to be writing systems code and numerical code. There is then some inertia keeping the most successful ones of from those periods going in their spaces.

Then these new languages with new ideas (GCs, Dynamic Typing, etc) they came out and became successful in the newer Web and Application spaces. Now why they won out and not LISP or SmallTalk or what have you, I am not sure. But my hypothesis is that the web is a big part of it.

Re: The evolution of Lua, continued [pdf]

#92

Post by kragen »

flykespice wrote: post #86
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.

Except they are? Lua 5.3 bitwise literals are a big improvement over the builtins bitand32, bitor.. the addition of integer type makes the language more suitable for embedded systems that don't have FPU.. Lua 5.4 added const attribute for local variables..

Those are tradeoffs, and I'm not convinced they're good ones. Suitability for processors that are so small they don't have an FPU isn't relevant to LuaJIT in any case, but you've been able to compile Lua with integer numbers since 1.0.

Re: The evolution of Lua, continued [pdf]

#93

Post by nmz »

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.

> It also won't stop you from accidentally overwriting a global variable that already exists.

That's also solvable using metatables.

Re: The evolution of Lua, continued [pdf]

#94

Post by thefaux »

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…

Lua has tail call optimization and js doesn't. For me, this is a dealbreaker for js.

Lua also has operational advantages compared to javascript. You can build it from source in at most a few seconds and run it anywhere that has a c compiler. The startup time is negligible even compared to a compiled c program so you can run entire scripts that do very useful things faster than most js engines can print hello world. There is also the benefit that in spite of what this article discusses, it is possible for most problems to write a lua solution that works for all lua >= 5.1. This is wonderful because it means if I stick to the standard library, the bitrot is essentially zero.

Calling into c is very straightforward in Lua, especially with luajit, which makes it superior to js as a scripting language (the node ffi api is quite painful in my experience and ffi runs against the js execution model).

Lua also essentially got lexical scoping of local variables correct from the beginning while js blessed us with the nightmare of var.

Of course Lua is far from perfect, but while there are some similarities, the differences are quite significant and meaningful.

Re: The evolution of Lua, continued [pdf]

#95

Post by nmz »

rebolek wrote: post #62

I don't understand why Python is so popular when there's Lua. It's just so much better. Not as good as Rebol but still much better than Python.

Rebol is the cleanest/greatest language I've read code for but the VM is the slowest VM I've ever wrote code for, mind you I only did the first 10 exercises of euler but the only thing that has it beat is writing a shellscript that forks to dc/bc on each math expression.

Re: The evolution of Lua, continued [pdf]

#96

Post by nmz »

strenholme wrote: post #40

Here’s my bit of public domain code for iterating through tables in Lua so that the elements are sorted. This routine works like the pairs() function included with Lua: -- Like pairs() but sorted function sPairs(inTable, sFunc) if not sFunc then sFunc = function(a, b) local ta = type(a) local tb = type(b) if(ta == tb) then return a Example usage of the above function: a={z=1,y=2,c=3,w=4} for k,v in sPairs(a) do print…

If you did not return a closure, you could set the metatables __pairs to use your function's. Sadly, you could not do this without keeping some sort of cache, which would be a terrible waste of memory, but then again you're already creating an iterator that iterates completely, to me, this beats the use of an iterator (to not iterate over everything and break on a single pass)

Re: The evolution of Lua, continued [pdf]

#98

Post by b_e_n_t_o_n »

hackthemack wrote: post #89
realharo wrote: post #72

Earlier quoted context omitted.

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 agree mostly in that Lua and Javascript are both similar, and like I said in my post above, I could see myself saying the exact opposite if Lua had been included in the browser. The things I do not like about Javascript can easily be shot down in an argument. Some of it was having to work with Javascript (and it's evil cousin JScript) in the 90s and early 00s. The type coercion and in the early days people used '==…

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.

Re: The evolution of Lua, continued [pdf]

#99

Post by jrop »

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

That's what I meant and didn't communicate well. I'm wishing for short-form syntax of lambdas, to be clear.

Re: The evolution of Lua, continued [pdf]

#100

Post by sieep »

flykespice wrote: post #79
sieep wrote: post #75

I've been saying it for years: Lua needs its Ruby on Rails moment

Hell no, keep it small as is, no influence from big corporations and no enshittification (or having a "DHH problem" in Lua community)

I see your point. I've just craved a rails-like experience in Lua for a while and don't believe there's anything out there yet built on Lua that can match with the big boys (rails, .NET, etc.)
Post reply on HN