5 ms·

Yeah, actually. Lua isn't as clean as Ruby (or Python, or your_favorite_language), but it has the advanced features you'd expect from a powerful scripting lang

• LogicHoleFlaw 18y ago
  Are you serious? Lua has an extremely clean and orthogonal core. It's got serious CS mojo. The "batteries not included" bit is probably the greatest detraction to Lua as a general-purpose scripting language.
  • palish 18y ago
    Certainly. I didn't mean to deride anyone's work with the comparison. I meant, some of the implementation decisions seem arbitrary, and seem like they were made "for the sake of being different". For example, Lua's use of two dashes for line comments, and --[[ and --]] for block quotes. That lets you remove the first --[[ in a block quote without causing the program to break, because the "closing" block quote is commented out at that point (because --]] is a comment at that point). But really, that's so different from other languages that it seems like a liability rather than an asset. That's what I meant by "not necessarily beautiful". It is definitely beautiful in certain other aspects, though. Also, if I were writing a scripting language, I'd love for it to be "like a prostitute". Even if nobody respected it, everyone would be using it.
    • Xichekolas 18y ago
      > Even if nobody respected it, everyone would be using it. By that metric, PHP is the scripting language for you. ;) The double hyphen comment is used elsewhere. SQL comes to mind.
    • davidw 18y ago
      In that vein, don't array indexes start with 1, instead of 0? Erlang does that too, and it's a bit weird, but not a show stopper.
      • palish 18y ago
        Right, exactly.
      • compay 18y ago
        Lua doesn't even really have arrays per se, but rather "tables," which are a light, flexible data structure somewhat similar to Javascript's objects. You're free to index tables starting with 0 if you really want to, but the convention in Lua is to use 1.
        • LogicHoleFlaw 18y ago
          This is slightly less true than it used to be. The table length "#" operator returns the index of the largest integer key continuously reachable from the index at 1. (i.e. there can be no integer keys with nil values in between). This, as well as a handful of standard library operators, rely on the index-from-1 convention. Tables in Lua can be thought of as discrete mappings of any value as key, to any value as value. The reference implementation happens to have the property that if you index from 1 upwards by increments of 1 that all of those values are kept in a single C array which is then subscripted in the usual fashion. It's a handy thing to know when you decide how to lay out your data. The "dictionary" portion of the table only springs into existence when something is actually inserted into it. Actually if I understand correctly, an empty Lua table is basically just a pointer to a minimal structure in memory, so it can be used for identity comparisons and so on where only uniqueness is necessary, rather than a full array+dict functionality with the associated memory overhead. Lua tables are extremely flexible and powerful. Especially when combined with the "metatable" concept.
          • bayareaguy 18y ago
            The table length "#" operator returns the index of the largest integer key continuously reachable from the index at 1. (i.e. there can be no integer keys with nil values in between). This, as well as a handful of standard library operators, rely on the index-from-1 convention. That does not always hold true. The '#' operator is weird. Here is an example: Lua 5.1.3 Copyright (C) 1994-2008 Lua.org, PUC-Rio > x = {1,2,3} > x[1] = nil ipairs() stops at the first nil, as expected: > for i,v in ipairs(x) do print(i,v) end However #x is inaccurate now: > print(#x) 3 Luckily, we can always see all the values with pairs(): > for k,v in pairs(x) do print(k,v) end 2 2 3 3 And watch what happens when we add a single non-integer key to the array: > x.a = 10 > print(#x) 1 > Looking at http://www.lua.org/source/5.1/ltable.c.html#luaH_getn http://www.lua.org/source/5.1/ltable.c.html#luaH_getn I think the problem lies in the assumption in luaH_getn that if the table doesn't have an 'hash' part then it also doesn't have any gaps. /* ** Try to find a boundary in table `t'. A `boundary' is an integer index ** such that t[i] is non-nil and t[i+1] is nil (and 0 if t[1] is nil). */ int luaH_getn (Table *t) { unsigned int j = t->sizearray; if (j > 0 && ttisnil(&t->array[j - 1])) { /* there is a boundary in the array part: (binary) search for it */ unsigned int i = 0; while (j - i > 1) { unsigned int m = (i+j)/2; if (ttisnil(&t->array[m - 1])) j = m; else i = m; } return i; } /* else must find a boundary in hash part */ else if (t->node == dummynode) /* hash part is empty? */ return j; /* that is easy... */ else return unbound_search(t, j); }
    • tokipin 18y ago
      the [[ and ]] are used for literal/multiline strings, so they make sense in block quotes. and you don't have to end the block with --]]. ]] is fine, which is the only thing i've ever used since it would never have occurred to me, especially as an anemic commenter, to use that quoting trick the [[ and ]] can be extended to nest strings/comments like so: --[==[ function add( a, b ) --[[ return a + b ]] return a - b end ]==] you can use [=[ ]=], [====[ ]====] etc
      • silentbicycle 18y ago
        With the number of equals matching on the opening and closing comments.