Broken lexical scoping: assignment acts as declaration, clobbering global variables.
Lexical scoping is there with
local variables. Yes, global by default is annoying, that's why many use a patch or strict.lua to prevent accidental global variable creation inside of functions.
Moreover, every variable access goes through hashtable system, producing several L2 cache misses in process
Unless you use luajit, in which case it turns typical "object.member" looking lookups into simple constant field accesses.
making Lua slower than comparable alternatives, like Lisp.
What Lisp? Common Lisp? Too fucking big to embed, unless you use something like CLISP which is going to perform worse than luajit or probably even PUC-RIO Lua and isn't acceptible due to its use of the GPL, or ECL which requires the user to have a C compiler installed and thus unacceptable for Lua's use cases (games and scripting languages for data editing and visualization tools)
Scheme? There is no good Scheme that approaches Luajit's performance and ease of embeddability. Stalin is AoT compiled so not useful for this niche and it's abandoned anyway, most of the Schemes are incredibly bloated, the embeddable ones are even more limited than Lua and don't have incremental GCs necessary for stutter-free operation.
Hash-Table as a primary data structure has overwhelming issues. There is no simple and safe way to implement Lisp-like FIRST and REST functions
Stop thinking in a different language, just iterate over the table with a
for k,v in pairs(t) loop.
sequential access is somewhat slow
Luajit and even PUC-RIO Lua turn numerically indexed tables into vectors nowadays.
There is no easy way to remove an element from a list.
t.k = nilTable indexing starts from 1
I'll agree on this one, it still pisses me off.
meaning there is no easy way to do functional programming with Lua.
That's a good thing,
THE FORCED GENERATION OF SUPERFLUOUS GARBAGE has no place in a game.
while table construction syntax and semantic are impenetrably confusing, like { [f(1)] = g; "x", "y"; x = 1, f(x), [30] = 23; 45 }
You're mixing the syntax for array tables and hashtables into one construction, of course it's going to look weird, and of course no one ever does this in practice.
Lua uses floating point values to represent integers, so 9999999999999999999==10000000000000000000
If you really need to represent an integer larger than 2^52, luajit's FFI supports 64 bit integers.
Things could be unequal to itself: `t={[{1,2,3}]="abc"}; print(t[{1,2,3}])` wont print "abc", meaning that `{1,2,3} != {1,2,3}`.
This is equivalent to the
= vs. eqv? vs. equal? trichotomy in Lisps. You're comparing their identity, of course they're not the same.
Moreover, `t = {"a","b","c"}; print(t[2])` works, but `print({"a","b","c"}[2])` fails.
Why would this ever matter
`print 'hello';` works, but `print 123;` fails.
That's because Lua allows you to skip the parenthesis for function calls with a string as their only parameter.
Lua is unstable: API changes frequently, functions are being added and deleted continuously,
Oh wow Nikita, Lua is one of the slowest changing languages in common use, and in practice everyone uses 5.1 anyway because that's what Luajit is based off of.
Lua's GC is a naive mark-and-sweep implementation
Not true for Luajit, and even Lua has incremental GC now.
That makes typical Lua user a teenage gamer with little expectations or taste for computation features and productivity.
lol
I'm disappointed in you, Nikita, and disappointed in
>>21-san for reposting that. Almost all of those flaws are either complete non-issues or simply not true. If you're going to bitch about Lua, at least bitch about things that actually make a difference like how the standard library is almost as useless as R5RS's.