>>28You can defend it all you want, but without that kind of criticism, LuaJIT might not even exist. That and other criticism is well-deserved. From my point of view:
Performance should never have been an issue. Look at Io--it doesn't have a fancy JIT or a real VM, but it pretty much always had optimizations that put the "we're so legit you have to pay us for docs" Lua to shame. Getting schooled by one of the fly-by-nights you so casually insult.
Metatables are an antipattern, especially in proto-oo where you can usually achieve the same thing with less mess by relying on the language semantics. But like Javascript, Lua hates its proto-oo heritage and doesn't do it justice. Why even bother?
1-based indices are stupid and effectively impossible to fix. What little library support Lua has presumes it.
Assignment is either by ref or by copy, depending on undocumented semantics. I've observed an alarming number of copies. So much for avoiding superfluous garbage.
Embedding Lua isn't as nice as you think. Lua makes a mess of the stack whenever something goes wrong. You can make this work with C, but if you want it to work with anything else you've got a lot of low-level code to write. No wrappers, huh?
The array indexing thing wouldn't be bad if Lua behaved more like a functional or array-based language. There's no good reason for prototypes in Lua as it stands, it does proto-oo a disservice and it does Lua a disservice. Everything sucks hard to embed: Lua, Scheme, Perl, Io, Ruby, Python, Javascript--unless you're embedding it in C, then it's usually manageable. You've still got the vomit bag that is GC and exception interop to worry about.
The only really good thing about Lua is LuaJIT. It's actually good enough to make Lua worth using, since it is small and pretty fast and sometimes that's all you care about. But defending Lua the language? Why?