8 ms·

Here's an article I've submitted before that makes a case for considering Squirrel instead of Lua: http://computerscomputing.wordpress.com/2013/02/18/lua-and-s

by vor_ 14y ago

Here's an article I've submitted before that makes a case for considering Squirrel instead of Lua: http://computerscomputing.wordpress.com/2013/02/18/lua-and-squirrel-the-case-for-squirrel/ http://computerscomputing.wordpress.com/2013/02/18/lua-and-s... The best reason against using Lua in my mind is that undefined variables in Lua return nil, which can lead to typo bugs and therefore unintentional sparse arrays, which screws up the result returned by the length operator. It also has inconsistent boolean expression evaluation: while 0 do print("Loops forever") end while not 1 do print("Does nothing") end while 1 do print("Loops forever") end while not 0 do print("Does nothing") end It's nice having real classes in Squirrel with type introspection and corresponding C APIs. In Lua, I have to juggle metatables in the registry to construct a class system, and my system will differ slightly from someone else's. Squirrel's other niceties like compile-time constants, 0-based arrays, and automatic reference counting for predictable memory management overhead make it a quite nice alternative to Lua. It sounds like I'm bashing Lua here, though I still find it fun to program occasionally. But I do wonder how long Lua can remain as popular as it is with an unconventional syntax, inconsistent behavior, and a minimal built-in library in the face of richer alternatives like Squirrel, mruby, and even Tcl, which has improved much in recent years. There must have been a reason Valve Software chose to use Squirrel in L4D2 and Portal 2 instead of using Lua as most apparently do.

Fargren 14y ago
Correct me if I'm wrong, but what's inconsistent there is not boolean evaluation, it's number to boolean conversion. 1 == true and 0 == false are pretty standard, but that doesn't mean 0 and 1 are booleans.
- vor_ 14y ago
  Only nil and false evaluate to false. Because there's no distinction between nil and non-existent elements, checking the existence of an element with a value of 0 requires that 0 evaluates to true, so you get this situation: while 0 do print("loops forever") end while not 0 do print("does nothing") end
  - spicyj 14y ago
    What you're saying is just that in Lua, 0 is truthy. Ruby is the same way, not a big deal.
Avshalom 14y ago
That's not inconsistent. Unintuitive maybe.
- vor_ 14y ago
  You don't consider it an inconsistency for (1) and (not 0) to evaluate to different results?
  - Avshalom 14y ago
    0 isn't false.
    - vor_ 14y ago
      It's also not true: > if 0 then print "true" end true > 0 == true => false I know why this is the case. But it's a logical inconsistency for users of the language.
      - ufo 14y ago
        Stop trolling please. You are advocating for `==` doing type coercion of arguments and that is almost always a misfeature in any language that has that (and the fix usually involves adding an ugly `===` operator after the fact)
  - akavi 14y ago
    Would you consider that an inconsistency if you weren't coming from the C paradigm of 0 == false?
    - vor_ 14y ago
      Yes, because it's not just a C paradigm. Additionally, even though 1 is true, comparing 1 and true returns false!
      - Stratoscope 14y ago
vardump 14y ago
It's not inconsistent at all. In Lua, only nil and false are not true. Everything else is true, including all integer values, strings "0", "false", "", etc. I'd rather say Lua is one of the most consistent and logical languages when it comes to truth values. You don't ever have to worry about arbitrary value evaluating to false. http://www.lua.org/pil/3.3.html http://www.lua.org/pil/3.3.html
- vor_ 14y ago
  Lua's treatment of boolean expression does lead to inconsistencies. For example: function Func1() return 1; end function Func2() return true; end if(Func1() == Func2()) then print "They're both the same!" else print "They're different!" end In Lua, even though 1 and true evaluate to true, they're not the same thing and so comparisons between them evaluate to false!
  - graue 14y ago
    1 and 2 both evaluate to true, yet they're not the same thing, so the comparison `1 == 2` is false. Is that equally problematic to you? There's no way to avoid this problem in any language that allows coercing a number to a boolean. There are two possible boolean values, and many more possible numeric values. Therefore, numbers that are different and compare unequal will still both evaluate to true. Pigeonhole principle. It seems you were surprised by the fact that Lua doesn't consider 0 false. Fair enough, that behavior's different from many other programming languages. But there's nothing inconsistent about it.
    - vor_ 14y ago
      You're explaining the implementation, which I understand. There are reasons behind everything in the infamous "Wat!" video. The inconsistency is in conceptual expectations: (0) is true, (not 0) is false, yet (0 == true) is false. These are unexpected "gotchas" familiar to experienced Lua programmers. It's not a dealbreaker. It's just a Lua quirk that often surprises newcomers. I was pointing out that Squirrel uses more conventional boolean evaluation that script authors coming from other languages may be more comfortable with. If you're exposing a scripting API, the language you use is essentially a part of your user interface.
goldfeld 14y ago
One more language with a C syntax, how so exciting. If for nothing else, I love Lua for taking all the good simplicity out of Python and meshing it with a functional approach and everything is a table. Arguing over syntax aesthetics might be superficial, but I welcome some variety thank you very much, same as I would be bored as a writer if I could only use one style.
Stratoscope 14y ago
Thanks for posting that link. I've been interested in Squirrel myself and will check it out. I do like Lua and - per the discussion below - I don't see any problem in Lua's concept of truthiness. It's different from other languages like C or JavaScript, but similar to others like Ruby. Just something you have to get used to if you program in multiple languages. But the other things you mentioned do sound worthwhile, so thanks!
omaranto 14y ago
If I understood your comments in this thread correctly what you are calling an inconsistency is that there are many values x for which if x then print "OK" end prints "OK" but for which x == true returns false. Is that right? If it is, then this is completely normal for languages that allow non-booleans in if statements. For example, x=2 is "inconsistent" in very many languages such as C, Python, Ruby, Perl, most Lisps, etc. I've never heard of this Squirrel language before, but if I read the docs correctly, x=2 is also "inconsistent" in Squirrel. In fact I'd be very surprised by a language that had no "inconsistent" values of x and that didn't achieve this by simply restricting x to be Boolean in an if.

by vor_ 14y ago

Fargren 14y ago

Correct me if I'm wrong, but what's inconsistent there is not boolean evaluation, it's number to boolean conversion. 1 == true and 0 == false are pretty standard, but that doesn't mean 0 and 1 are booleans.

vor_ 14y ago
Only nil and false evaluate to false. Because there's no distinction between nil and non-existent elements, checking the existence of an element with a value of 0 requires that 0 evaluates to true, so you get this situation: while 0 do print("loops forever") end while not 0 do print("does nothing") end
- spicyj 14y ago
  What you're saying is just that in Lua, 0 is truthy. Ruby is the same way, not a big deal.

Avshalom 14y ago

That's not inconsistent. Unintuitive maybe.

vor_ 14y ago
You don't consider it an inconsistency for (1) and (not 0) to evaluate to different results?
- Avshalom 14y ago
  0 isn't false.
  - vor_ 14y ago
    It's also not true: > if 0 then print "true" end true > 0 == true => false I know why this is the case. But it's a logical inconsistency for users of the language.
    - ufo 14y ago
      Stop trolling please. You are advocating for `==` doing type coercion of arguments and that is almost always a misfeature in any language that has that (and the fix usually involves adding an ugly `===` operator after the fact)
- akavi 14y ago
  Would you consider that an inconsistency if you weren't coming from the C paradigm of 0 == false?
  - vor_ 14y ago
    Yes, because it's not just a C paradigm. Additionally, even though 1 is true, comparing 1 and true returns false!
    - Stratoscope 14y ago

vardump 14y ago

It's not inconsistent at all. In Lua, only nil and false are not true. Everything else is true, including all integer values, strings "0", "false", "", etc. I'd rather say Lua is one of the most consistent and logical languages when it comes to truth values. You don't ever have to worry about arbitrary value evaluating to false. http://www.lua.org/pil/3.3.html http://www.lua.org/pil/3.3.html

vor_ 14y ago
Lua's treatment of boolean expression does lead to inconsistencies. For example: function Func1() return 1; end function Func2() return true; end if(Func1() == Func2()) then print "They're both the same!" else print "They're different!" end In Lua, even though 1 and true evaluate to true, they're not the same thing and so comparisons between them evaluate to false!
- graue 14y ago
  1 and 2 both evaluate to true, yet they're not the same thing, so the comparison `1 == 2` is false. Is that equally problematic to you? There's no way to avoid this problem in any language that allows coercing a number to a boolean. There are two possible boolean values, and many more possible numeric values. Therefore, numbers that are different and compare unequal will still both evaluate to true. Pigeonhole principle. It seems you were surprised by the fact that Lua doesn't consider 0 false. Fair enough, that behavior's different from many other programming languages. But there's nothing inconsistent about it.
  - vor_ 14y ago
    You're explaining the implementation, which I understand. There are reasons behind everything in the infamous "Wat!" video. The inconsistency is in conceptual expectations: (0) is true, (not 0) is false, yet (0 == true) is false. These are unexpected "gotchas" familiar to experienced Lua programmers. It's not a dealbreaker. It's just a Lua quirk that often surprises newcomers. I was pointing out that Squirrel uses more conventional boolean evaluation that script authors coming from other languages may be more comfortable with. If you're exposing a scripting API, the language you use is essentially a part of your user interface.

goldfeld 14y ago

One more language with a C syntax, how so exciting. If for nothing else, I love Lua for taking all the good simplicity out of Python and meshing it with a functional approach and everything is a table. Arguing over syntax aesthetics might be superficial, but I welcome some variety thank you very much, same as I would be bored as a writer if I could only use one style.

Stratoscope 14y ago

Thanks for posting that link. I've been interested in Squirrel myself and will check it out. I do like Lua and - per the discussion below - I don't see any problem in Lua's concept of truthiness. It's different from other languages like C or JavaScript, but similar to others like Ruby. Just something you have to get used to if you program in multiple languages. But the other things you mentioned do sound worthwhile, so thanks!

omaranto 14y ago

If I understood your comments in this thread correctly what you are calling an inconsistency is that there are many values x for which if x then print "OK" end prints "OK" but for which x == true returns false. Is that right? If it is, then this is completely normal for languages that allow non-booleans in if statements. For example, x=2 is "inconsistent" in very many languages such as C, Python, Ruby, Perl, most Lisps, etc. I've never heard of this Squirrel language before, but if I read the docs correctly, x=2 is also "inconsistent" in Squirrel. In fact I'd be very surprised by a language that had no "inconsistent" values of x and that didn't achieve this by simply restricting x to be Boolean in an if.