Pros:
* Tiny
* Crossplatform
* Easy to embed
* Fairly easy to extend
* Has no external dependencies
* Easy to learn due to simple syntax
* Has metatables, which allow creating objects, and with that, allow OOP
Contra:
* The builtin stdlib doesn't allow much more than just basic IO
* The stackoriented API might be confusing to those unfamiliar with the concept of stackbased APIs
* Due to the do ... end syntax, closures and co tend to look clumsy:
pcall(function()
stuff ...
end)
>>1
Lua metatables suck shit, the tables-as-the-base-datastructure would have worked fine if it wasn't for how shitty they are. The semantics are so close to be Lispy, yet so far ;_;. Lua's failure makes me sad and angry. If only...
Their scoping rules are broken. "Global by default" is shit. All code looks like
local local local local local
local local local local local
local local local local local local local local
local local local local
local local local local local local local local local local
local local local
>>23 ARE YOU anoperator?
ARE YOU foreverything?
ARE YOU anoperatorforeverything?
If you answered ``Yes'' to all the above, Perl 6 might be exactly what you've looking for!
I prefer Squirrel to Lua, it uses C-like braces instead of end, it has OO instead of the cludgy OO in Lua. The only thing I dont like in Squirrel and Lua is having to explicitly declare variables as local. I'll stick to Python and Ruby thank you.
>>34
The only reason OO is kludgy in Lua is because metatables are utterly broken. As for declaring variables as local manually, that's a great indicator of a sane language (though it doesn't apply to C++ and Java).
>>37
Call me the ``\`\`\\\`\\\`\\\'\\\\\\\`\\\\\\\`\\\\\\\\\\\\\\`\\\\\\\\\\\\\\`in Lisp\\\\\\\\\\\\\\'\\\\\\\\\\\\\\' guy\\\\\\\'\\\\\\\'\\\'\'\'''
Name:
Anonymous2011-01-22 20:30
>>36
Is there a summary somewhere of what is wrong with Lua metatables? Do you mean the particular implementation details in Lua, or the general concept?
>>39 Do you mean the particular implementation details in Lua, or the general concept?
Both. There are things you can override in metatables, and there are things you can't. That's really bad.
Name:
Anonymous2011-01-22 21:02
>>36,40
I prefer Lua's object model (i.e. protos, not classes), especially for scripting. But one thing I dislike in OO is meta-anything and Lua's metatables are so broken and/or not completely documented in 5.1 (unless you want to buy the book.) It's a real turn-off. For OO scripting I'm most fond of Io: http://www.iolanguage.com/
Another thing I've found is braces aren't that important. As long as blocks are delimited consistently and by something other than weird whitespace configurations I am usually fine with it.
>>41 I prefer Lua's object model (i.e. protos, not classes)
Why do prototype based OO languages always suck? I love prototypes, but: Lua sucks, JS sucks, Io is RUBY AS FUCK.
>>43
It's shitnamyc typed, has too many gotchas and dos and don'ts.
And no, === and !== solve just one problem.
I hope ECMAScript ``Harmony'' will fix JS, it's the only language I'd use other than Lisp and C. I doubt it though.
>>45
Gotcha. I the gotchas are mostly the ever multiplied product of things MS did in IE. One thing about Harmony is the opt-in strategy. I don't know how well that will work out, but if it does it may bring a lot of relief to the existing problem of support for terrible decisions made in the past.
The type coercion hasn't given me any serious problems. Given that it's meant for web designers to ruin their sites with, I would have expected a far worse situation... I think we're getting off easy.
>>48 The type coercion hasn't given me any serious problems.
A flaw is still a flaw, they need to get rid of it.
Also, I'd like macros.
Name:
Anonymous2011-01-23 23:57
>>49
But all languages are flawed. Type coercion in Lua is such a minimal thing by comparison with the other flaws in the language and in the flaws in other candidate languages. Sure it should get fixed, but I'd sooner see documentation. Maybe there's a new metatable field that I can use to fix it myself.
>>51
Oh right. Oops. Same deal, really... only without the rest of the problems in the language. I mean if you code for a specific JS engine you're fine.