5 ms·

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

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
    personally i think 0-indexing is weird. it makes sense as a pointer offset in lower-level languages. but in higher-level languages we have the opportunity to index the first element by the number 1, the second by the number 2, and so on instead of having to do that little -1 every time which is something that has to be learned
    - enqk 18y ago
      There is a short note by Dijkstra about this http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EW...
      - tokipin 18y ago
        that's really weird. was it written at a time when most programming was for scientific purposes? i don't know my comp history if i parsed it correctly, he is saying that things should be 0-indexed because a particular mathematical notation corresponding to it is more sensical, but i don't see what mathematical notation has to do with programming notation, both of which are man-made, arbitrary, and for different purposes, such that reasoning about either with respect to the other is imo fallacious he compares subscript ranges in a notation where 0-indexing appears to be better, but choosing a different notation (such as b in his examples) makes it look better for 1-indexing ( 0 < i <= N versus -1 < i <= N-1 )
        critic 18y ago
        Here is the important part: Extensive experience with Mesa has shown that the use of the other three conventions has been a constant source of clumsiness and mistakes 0-based indexing is not something you can rigorously prove to be better.
        silentbicycle 18y ago
        One advantage of 0-based is that using array[mod(i, length)] works. It mostly seems to me like 0-based vs. 1-based is a relatively arbitrary decision, though. Each just leads to fencepost errors in different places.
- 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.

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
  personally i think 0-indexing is weird. it makes sense as a pointer offset in lower-level languages. but in higher-level languages we have the opportunity to index the first element by the number 1, the second by the number 2, and so on instead of having to do that little -1 every time which is something that has to be learned
  - enqk 18y ago
    There is a short note by Dijkstra about this http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EW...
    - tokipin 18y ago
      that's really weird. was it written at a time when most programming was for scientific purposes? i don't know my comp history if i parsed it correctly, he is saying that things should be 0-indexed because a particular mathematical notation corresponding to it is more sensical, but i don't see what mathematical notation has to do with programming notation, both of which are man-made, arbitrary, and for different purposes, such that reasoning about either with respect to the other is imo fallacious he compares subscript ranges in a notation where 0-indexing appears to be better, but choosing a different notation (such as b in his examples) makes it look better for 1-indexing ( 0 < i <= N versus -1 < i <= N-1 )
      - critic 18y ago
        Here is the important part: Extensive experience with Mesa has shown that the use of the other three conventions has been a constant source of clumsiness and mistakes 0-based indexing is not something you can rigorously prove to be better.
        silentbicycle 18y ago
        One advantage of 0-based is that using array[mod(i, length)] works. It mostly seems to me like 0-based vs. 1-based is a relatively arbitrary decision, though. Each just leads to fencepost errors in different places.
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.