>>31
Whoa, boy.
Lua Tables are mutable and encourage modification, instead of creation, meaning there is no easy way to do functional programming with Lua.
Lua was designed to be a high-level scripting/configuration language for applications written in C. In C, Lua tables are built piece by piece. They represent everything from arrays to hash tables to environments. What possible benefit could come from making them immutable? And what good would be functional bindings to C code?
In general, Lua's logic seems odd: "nil+1" results in error, while "(not nil)+1" eval to 2.
nil is a not a number. 1 is a number. 1 is not nil. Booleans are represent as integers, just as they are in C. How is this not logical?
1234567890123456789 would result into 1.234567890123457e+18
Lua doesn't have bignums. Large integers are converted to doubles. It's unlikely that an exact integer that large would be useful, for say, indexing an array. Lose in precision is better than overflows.
Lua is unstable: API changes frequently, functions are being added and deleted continuously, `table.foreach` being a good example of to be deleted function, and then there is `table.unpack`, which present only in some versions of Lua.
Lua is the only language that has ever deprecated a function? Some people insist on using version 4.x because it's simpler. The current version is 5.x. Since when are major versions of scripting languages meant to be backwards compatible?
Lua is inconsistent: `t = {"a","b","c"}; print(t[2])` works, but `print({"a","b","c"}[2])` fails.
In C
char *s = "abc"; putchar(s[1]); works but
putchar("abc[1]"); fails. Not understand the lexical conventions of the language you're programming in does not make the language inconsistent.
Hash-Table as a primary data structure has some issues
What does this have to do with Lua? Lua tables are not hash tables, though there is an abstraction to interface them as such.
Lua's REPL wont pretty-print tables
C doesn't pretty-print arrays. What's your point?
Hashtables hold much of Lua's data, and even simple variable access goes through table system, producing several L2 cache misses in process just to get to value. That makes Lua slower than comparable alternatives, like Lisp.
Symbols in Lisp are accessed through hash tables.
Table indexing starts from 1, instead of 0, like everything in computing
Except Matlab, to which Lua is syntactically similar. In any case, it's consistent with how the Lua stack is indexed in the C API. In some cases, it makes sense and/or is mandatory to iterate the stack incrementally from the bottom (1) and sometimes it makes sense and/or is mandatory to iterate the stack decrementally from the top (-1).
Lua's GC is a naive mark-and-sweep implementation
That was a long time ago. There's a new incremental GC now.
Lua was built as a glue language, and it shows.
Lua was built as high-interface to low-level code, and it shows, because there's not a single language that does it better.