Live data from Hacker News

The evolution of Lua, continued [pdf]

lua.org

161–170 of 175 posts

Re: The evolution of Lua, continued [pdf]

#161

Earlier quoted context omitted.

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.

The origin of this rule was that Douglas Crockford doesn't like ++.

From JavaScript: The Good Parts (May 2008):

> The ++ (increment) and -- (decrement) operators have been known to contribute to bad code by encouraging excessive trickiness. They are second only to faulty architecture in enabling viruses and other security menaces. The JSLint option plusplus allows the use of these operators.

Needless to say, I'm with you and hackthemack on this.

Re: The evolution of Lua, continued [pdf]

#163
post #94

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…

If I remember correctly, TCO is now part of the ECMAScript standard. Safari has implemented it. The issue is that others engines have not because they are concerned about stack unwinding and stacktraces.

Re: The evolution of Lua, continued [pdf]

#164
post #31

Lua is the SQLite of program languages, absolutely blast

Lua is the glue when sh/bash doesn't suffice. Lua is simple and elegant, and I much prefer it to Tcl. Lua is in games and in LuaTeX, and when you have the choice of embedding a LISP, a FORTH or Lua in a larger application, it is often the most maintainable, runtime-efficient and low-memory footprint option of all.

People don't normally embed FORTH in a larger application.

Re: The evolution of Lua, continued [pdf]

#165
post #73

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.

column types are more like guidelines than rules

Re: The evolution of Lua, continued [pdf]

#166
post #123

Earlier quoted context omitted.

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.

Yes, and there's nothing wrong with that. It doesn't result in the same degree of fragmentation in Lua as it did in the Python 2/3 split, because it's both socially accepted and usually technically easy to write code that works in both Lua 5.1 and Lua 5.4 and everything in between.

Re: The evolution of Lua, continued [pdf]

#167
post #94

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…

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

That was not my experience when I was working with lua. Did anything change since? Asked google. Answered :

> In Lua, if a variable is assigned a value inside a function without being explicitly declared with the local keyword, it will automatically become a global variable. This is because, by default, all variables in Lua are global unless explicitly specified as local.

Re: The evolution of Lua, continued [pdf]

#168
post #94

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…

I think a lot of people are missing this part, weighing things like 1 based indexing and curly brackets.

All of that is trivial when you consider the Lua reference implementation. It is beautiful.

Re: The evolution of Lua, continued [pdf]

#169

When comparing speed I use simple tests like a loop printing an incremented line number or reading from stdin and printing to stdout. These simple tests are useful for me because, when combined with pattern matching or regular expressions, simple I/O tasks like these are actually what I use a "memory safe" language for dino is slightly faster than lua (not luajit) but spitbol is actually faster than lua, dino and lua…

For me,

statically-linked 64-bit spitbol is only 175k

static-pie luajit 2.1 is 667k

static-pie lua 5.1.5 is 259k

static-pie ngn k is 271k

Re: The evolution of Lua, continued [pdf]

#170
post #131

Earlier quoted context omitted.

Regarding C# and Java part of your comment, I think you might want to take a look at the following Wikipedia entries: - Microsoft Java Virtual Machine: https://en.wikipedia.org/wiki/Microsoft_Java_Virtual_Machine - Visual J++: https://en.wikipedia.org/wiki/Visual_J%2B%2B

I've known and worked with James Gosling for years before Java (Live Oak), on his earlier projects, Emacs at UniPress and NeWS at Sun, and fought along side him against Sun management trying to make NeWS free in 1990 (and I left Sun because they broke the promises they made us and spilled a lot of blood), so I didn't need to learn about Java's history from Wikipedia. James's email that convinced me to go work with hi…

I think alasr meant to suggest that you might learn more about the history of C# by reading Wikipedia, not about the history of Java.
Post reply on HN