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

141–150 of 175 posts

Re: The evolution of Lua, continued [pdf]

#141

Post by jay_kyburz »

112233 wrote: post #116
spacechild1 wrote: post #115

Earlier quoted context omitted.

For me, JS has just too much magic, in particular the behavior of 'this', and lots of weird quirks, like "for in" vs. "for of". Lua, on the contrary, is very predictable and therfore easy to understand. One killer feature of Lua (that surprisingly few scripting languages have) is stackful coroutines, i.e. you can yield across nested stack frames. Unlike JS or Python, there is no artificial split between generators an…

Have you read large Lua codebases written by others? It is write-only language. All your "very predictable" features are overloadable, at runtime. No static typing to rest your eye on. It is a swamp. "But, just write good code" you will say. Just like with Perl, some languages are designed in a way to discourage writing good code...

Yes, I was going to write this comment a few hours ago but never got around to it. Working on other peoples Lua can be very painful.

Even the fact that people really want to write object oriented code, but every project rolls its own class system is a problem.

When I write lua is just tables of data and functions. I try to keep it as simple as possible.

I've been enjoying writing games for the Playdate, and in Love2d.

Re: The evolution of Lua, continued [pdf]

#142

Post by SkiFire13 »

thefaux wrote: post #94
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…

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. T…

> 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).

As a scripting language for browsers this is an antifeature, and the fact Lua comes by default with a bunch of features that allow loading arbitrary binary code in the process makes it pretty annoying to properly use it as a sandboxed scripting language.

Re: The evolution of Lua, continued [pdf]

#143

Post by doubleorseven »

spacechild1 wrote: post #115
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…

For me, JS has just too much magic, in particular the behavior of 'this', and lots of weird quirks, like "for in" vs. "for of". Lua, on the contrary, is very predictable and therfore easy to understand. One killer feature of Lua (that surprisingly few scripting languages have) is stackful coroutines, i.e. you can yield across nested stack frames. Unlike JS or Python, there is no artificial split between generators an…

if Lua had zero-based indexing it won't be Lua. also removing '.length - 1' globally will reduce gas emissions by 1% worldwide (my guess)

Re: The evolution of Lua, continued [pdf]

#144

Post by Rohansi »

kragen wrote: post #123
Rohansi wrote: post #122

Earlier quoted context omitted.

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.

New applications using LuaJIT will continue to be on Lua 5.1. And applications that do upgrade their dependencies but use LuaJIT are going to be stuck on 5.1 maybe forever, too.

Re: The evolution of Lua, continued [pdf]

#145

Post by codebolt »

sieep wrote: post #75

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

For many, Lua is primarily known as the Roblox language. Pretty impressive that it's the language of use in a game (/set of games) with 380 million monthly active players - currently the most popular in the world.

Re: The evolution of Lua, continued [pdf]

#146

Post by 112233 »

spacechild1 wrote: post #120
112233 wrote: post #116

Earlier quoted context omitted.

Have you read large Lua codebases written by others? It is write-only language. All your "very predictable" features are overloadable, at runtime. No static typing to rest your eye on. It is a swamp. "But, just write good code" you will say. Just like with Perl, some languages are designed in a way to discourage writing good code...

I'm talking about the core language, which I do find very predictable. You can go crazy with any language. Lua is definitely not worse than Python or JS in this regard. > No static typing to rest your eye on. That goes for any dynamically typed language. How is that an argument against Lua in particular? > Have you read large Lua codebases written by others? No, because I use it as a scripting language, as intended.…

Oh, as a scripting language you embed into your project so that you can write scripts for it — there is hardly anything better than Lua. The C code is super clean and easy to embed and modify.

But once that project gets passed to next maintainer — I'm not sure I'd pick Lua over Forth or Scheme.

Re: The evolution of Lua, continued [pdf]

#147

Post by bvrmn »

boris wrote: post #73
SchwKatze wrote: post #2

Lua is the SQLite of program languages, absolutely blast

What would be the SQLite's equivalent to indexing starting from 1, not 0? Off the top of my head I can't think of anything that would go so much against the grain.

For me it's case insensitive LIKE.

Re: The evolution of Lua, continued [pdf]

#148

Post by stefanfisk »

b_e_n_t_o_n wrote: post #124
plopz wrote: post #119

Earlier quoted context omitted.

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.

Do people often use bundlers for the backend?

Re: The evolution of Lua, continued [pdf]

#149

Post by pjmlp »

112233 wrote: post #146
spacechild1 wrote: post #120

Earlier quoted context omitted.

I'm talking about the core language, which I do find very predictable. You can go crazy with any language. Lua is definitely not worse than Python or JS in this regard. > No static typing to rest your eye on. That goes for any dynamically typed language. How is that an argument against Lua in particular? > Have you read large Lua codebases written by others? No, because I use it as a scripting language, as intended.…

Oh, as a scripting language you embed into your project so that you can write scripts for it — there is hardly anything better than Lua. The C code is super clean and easy to embed and modify. But once that project gets passed to next maintainer — I'm not sure I'd pick Lua over Forth or Scheme.

I would pick Tcl instead, but I am biased. :)

Re: The evolution of Lua, continued [pdf]

#150

Post by pjmlp »

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.

Java 1996, C++ only got standardized in 1998, C in 1990 (tehcnically the standard is from 1989, but there was a short retification in 1990), Delphi is from 1995 (not that big player nowadays, but plenty of its influences live on C#, Typescript and Kotlin).

It goes to show how much investment is required for a programming language to actually take off at scale.

However in a couple of years, we will be asking the computers to perform tasks for us and the actually compiler frontend will be irrelevant to the AI runtime.

Post reply on HN