LUA is better than JavaScript
kasrajamshidi.com
kasrajamshidi.com
"Javascript is written in Java and meant to script Java programs"
"Javascript only runs on the JVM, which is only available on web browsers. That is only one platform. LUA runs on any CPU that can run assembly code, since LUA was written in C which is portable assembly. It is more portable."
Just one comment : please study more.
Clearly he has no clue of what he's writing about.
(that or dyslexia)
When you need a list, convention is to use a table with integer keys. But, the standard library functions dealing with these "lists" interpret the list as ending at the first element whose value is nil! There is no separate length field or anything (there was, but they took it out).
So, you can't just trust that a list is a generic structure that can hold anything -- you need to be on the lookout for "nil", because inserting it into a list truncates the list to that position.
There are many crazy workarounds for this: http://lua-users.org/wiki/StoringNilsInTables
But my workaround is to just not use Lua, because as many warts as JS has, it has nothing as bad as that IMO. It's a shame, because Lua is otherwise an excellent language.
EDIT: oh, I missed the first paragraph "I want to note that the language is technically called "Lua" and the authors explicitly request people to refrain from calling it LUA, but I always shout whenever I say it in real life", good troll :|
But I like that no one uses it. If people knew how much better Lua was over JavaScript, it might ruin the ecosystem with amateurs.
LUA doesn't have any of that functional baloney built into
it like Javascript. It doesn't have Objects either. Leave
that cruft to Java, Javascript, and all the other clunky
enterprise languages like them. Programming in LUA is the
way it's supposed to be, imperative.
Conclusion: LUA is hardcore and lightweight, like C.
Actually, Lua was intentionally designed to support functional programming and strong function composition. Lua supports proper tail calls and lexical closures. The former is necessary for functional programming, and the latter makes function composition easier as a practical matter, especially when you consider that...... one of the beauties of Lua is that you can write "Lua" in either Lua or C. That is, the Lua language was designed so that the Lua C API was a first-class citizen. A Lua function written in C has full access to the power of lexical closures as well as stackful coroutines. (See the paper "Passing a Language through the Eye of a Needle" at http://queue.acm.org/detail.cfm?id=1983083) No other language benefits from such attention to detail in that regard. If you don't understand the beauty of the Lua C API, then you don't understand Lua.
Also, object oriented programming in Lua is prototype based, just like in JavaScript. But Lua is definitely hardcore and lightweight and fast, even though it's a much more sophisticated language than both JavaScript and Python in terms of language abstractions.
I think people get the idea that Lua isn't sophisticated because it's so simple--that is, it has a small repertoire of language features, and the implementation is small and comprehensible. But that's largely a product of the fact that while Lua is over 20 years old, it never committed to strong backwards compatibility.
Lua 5.3 is the product of decades of ruthlessly discarding failed experiments, and carefully introducing new experiments. And this shows if you pay close attention to the details of the language features, semantics, and API.
For example, look at Lua's stackful coroutines. Some consider call/cc (call with current continuations) the ideal abstraction, but Lua's choice of asymmetric stackful coroutines was carefully considered. The paper 2004 paper "Revisiting Coroutines" (http://www.inf.puc-rio.br/~roberto/docs/MCC15-04.pdf) by one of the Lua authors is widely cited in this area of language research and design.
Lua's lack of backwards compatibility is a stumbling block for uptake. But it's asymptotically approaching the perfect language of it's kind (dynamically typed, etc). The period between major releases seems to be growing (5+ years now), and the changes fewer. The future is bright.