7 ms·

1-index kept throwing me off though

by umvi 6y ago

snazz 6y ago
It’s unfortunate that Lua makes some strange decisions, but the powerful functionality totally outweighs the weirdness (metatables are especially cool). I really like Lua, especially for game programming with LÖVE.
- DarkWiiPlayer 6y ago
  "strange" in the sense of different from other languages in 2020, yes, but not strange from the perspective of its developers. Lua is a language for both hardcore C programmers and complete n00bs wanting to configure their C programs. In that context, position-based indexing makes much more sense, as it's how most non-programmers think.
  - anonymoushn 6y ago
    I find it strange that you choose to use terminology that does not uniquely identify what you are talking about when the rest of the thread uses terminology that does uniquely identify what they are talking about
wafn 6y ago
I think 0-index causes a lot of new programmers (and non-programmers) confusion because they aren't used to treating 0 as a counting instance. For example, A.D. 2020 suggests that (allowing for the various changes and debates) Jesus was born 2020 years ago, instead of counting the first year which would make (2021-1 day) years ago. I see this every year around New Year, headlines saying "Actually, it will be [year + 1]"
shakna 6y ago
Once you get used to it, it does help prevent a whole bunch of off by one errors though, as you don't need math when grabbing a range. Like a string will always be: s:sub(1, #s) And a sequence table will always be: for i = 1, #t do t[i] end
- anonymoushn 6y ago
  I disagree. Particularly when parsing strings, it's useful if the upper bound of one substring is the lower bound of a nonoverlapping substring immediately after. For example, here's a routine to split a string into the part before the first dot and the part after: function split_dot(s) local idx = s:find(".", 1, true) if not idx then return s end return s:sub(1,idx-1), s:sub(idx+1) end It may come as a surprise that one should use a difference of 2 to skip over one character! In a language that used the half-open interval convention we would end up with: s:sub(0, #s) and for i = 0, #t do t[i] end which seem just as good to me.
  - shakna 6y ago
    You wouldn't end up with this: s:sub(0, #s) You would end up with: s:sub(0, #s - 1) Which demonstrates the off-by-one error.
    - anonymoushn 6y ago
      Can you explain what the intent of the code is and what the error is? It looks like the original code just grabs a substring containing the entire string. If the language used half-open intervals with an exclusive upper bound, the code I posted would also do that. In python, for example, the operation of copying a list can be correctly written l[0:len(l)]. You're more likely to see l[::] or list(l) though. Edit: I think maybe the proposed error that's being avoided is "a user tries to use a closed interval when sub takes a half-open interval." It seems like the opposite error is similarly likely though. Some areas where it's nice to have half-open intervals like using a modulus to restrict a value to an interval or parsing strings don't have such a symmetry. Notably if you're making a binary heap the formulas come out much nicer with 1-indexing than with 0-indexing, but I haven't met any other examples where this is the case.
      - shakna 6y ago
        If the language is using an exclusive upper bound, then it is correcting the mistake of the programmer for specifying a length beyond what the string contains. Lua does do that, so in this theoretical world with 0-indexed strings, it would still work as expected. But it doesn't change the fact that you're not actually specifying the right length - the language is correcting an off-by-one error, which means that the programmer's mental model is probably going to be wrong, and it will bite them when they don't expect it to. That's what off-by-one errors are - a place where the programmer's mental model doesn't actually fit the real world. It is better to not introduce places where they can happen in the first place, rather than to complicate things with edge cases where sometimes it works and sometimes it doesn't.
joan_kode 6y ago
The main problem with that decision is that every discussion having anything to do with Lua always devolves into repetitive bikeshedding about the 1-indexing.
- catblast 6y ago
  In the context of language design, the arguments for 0-based indexing rise above bikeshedding. https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/E... Sure it may not be the most critical point about language design, but it's not just bikeshedding either. For one thing, it is a language semantics issue rather than plainly syntax issue. I still like Lua, and maybe you don't even agree with Dijkstra's argument, which is also possible to make, but doesn't mean its bikeshedding - which seems to be a totally overused term to basically mean any argument I don't want to have.
  - soneca 6y ago
    Are you bikeshedding bikeshedding?? Just kidding, I actually agree with your point that the term is just demonstrate that you don’t want to have a conversation by diminishing the value of anybody having it.
  - skrebbel 6y ago
    Fwiw Dijkstra practically invented bikeshedding
    - andi999 6y ago
      bikeshedding considered harmful
  - pull_my_finger 6y ago
    Roberto Ierusalimschy makes an interesting point on this in an interview[1] last year. > When we started Lua, the world was different, not everything was C-like. Java and JavaScript did not exist, Python was in an infancy and had a lower than 1.0 version. So there was not this thing when all the languages are supposed to be C-like. C was just one of many syntaxes around. > And the arrays were exactly the same. It’s very funny that most people don’t realize that. There are good things about zero-based arrays as well as one-based arrays. > The fact is that most popular languages today are zero-based because of C. They were kind of inspired by C. And the funny thing is that C doesn’t have indexing. So you can’t say that C indexes arrays from zero, because there is no indexing operation. C has pointer arithmetic, so zero in C is not an index, it’s an offset. And as an offset, it must be a zero — not because it has better mathematical properties or because it’s more natural, whatever. > And all those languages that copied C, they do have indexes and don’t have pointer arithmetic. Java, JavaScript, etc., etc. — none of them have pointer arithmetic. So they just copied the zero, but it’s a completely different operation. They put zero for no reason at all — it’s like a cargo cult. [1] - https://habr.com/en/company/mailru/blog/459466/ https://habr.com/en/company/mailru/blog/459466/
TedDoesntTalk 6y ago
How about this: The empty string and 0 are truthy. Why?
- cl3misch 6y ago
  Maybe because all variables are `nil` by default, and checking on undeclared variables does not raise an error. So `if foo then ... end` is often used as an existence check, where `foo = 0` should be truthy.
- anonymoushn 6y ago
  This is probably a good thing, if you don't want to have tickets filed about whether midnight (time of day) is truthy, whether Jan 1, 1970 is truthy, why some type of empty collection is truthy but others are not, etc.
  - pansa2 6y ago
    > This is probably a good thing, if you don't want to have tickets filed about whether midnight (time of day) is truthy Agreed. Here is an example of exactly that in Python: https://bugs.python.org/issue13936 https://bugs.python.org/issue13936
- DarkWiiPlayer 6y ago
  0? Because Lua isn't C. It makes sense for C to treat 0 as falsey, because (void*)0 is Cs way of expressing a nil-value, as well as not having a dedicated boolean value to keep the language simpler. Lua, both has a dedicated nil value and a boolean type, so there's no reason whatsoever to treat zero as falsey, other than the C cargocult. As for empty strings, I really don't see the rationale behind it. An empty string is not nothing. At the very least, it still holds the length-data of 0, so it's conceptually more than just nil and should thus still be truthy.
- pansa2 6y ago
  If you make the empty string falsy, surely you need to make all empty collections falsy? Python does this, which leads to people checking whether a list is empty using `if l` rather than `if len(l) > 0`. I‘d rather they stuck with “explicit is better than implicit”.
pansa2 6y ago
Yes. There are pros-and-cons of 1-based indexing when considered in isolation. But for Lua, a language that’s commonly used tightly-coupled to C, 1-based indexing is extremely awkward.

1-index kept throwing me off though

by umvi 6y ago

1-index kept throwing me off though

It’s unfortunate that Lua makes some strange decisions, but the powerful functionality totally outweighs the weirdness (metatables are especially cool). I really like Lua, especially for game programming with LÖVE.

DarkWiiPlayer 6y ago
"strange" in the sense of different from other languages in 2020, yes, but not strange from the perspective of its developers. Lua is a language for both hardcore C programmers and complete n00bs wanting to configure their C programs. In that context, position-based indexing makes much more sense, as it's how most non-programmers think.
- anonymoushn 6y ago
  I find it strange that you choose to use terminology that does not uniquely identify what you are talking about when the rest of the thread uses terminology that does uniquely identify what they are talking about

wafn 6y ago

I think 0-index causes a lot of new programmers (and non-programmers) confusion because they aren't used to treating 0 as a counting instance. For example, A.D. 2020 suggests that (allowing for the various changes and debates) Jesus was born 2020 years ago, instead of counting the first year which would make (2021-1 day) years ago. I see this every year around New Year, headlines saying "Actually, it will be [year + 1]"

shakna 6y ago

Once you get used to it, it does help prevent a whole bunch of off by one errors though, as you don't need math when grabbing a range. Like a string will always be: s:sub(1, #s) And a sequence table will always be: for i = 1, #t do t[i] end

anonymoushn 6y ago
I disagree. Particularly when parsing strings, it's useful if the upper bound of one substring is the lower bound of a nonoverlapping substring immediately after. For example, here's a routine to split a string into the part before the first dot and the part after: function split_dot(s) local idx = s:find(".", 1, true) if not idx then return s end return s:sub(1,idx-1), s:sub(idx+1) end It may come as a surprise that one should use a difference of 2 to skip over one character! In a language that used the half-open interval convention we would end up with: s:sub(0, #s) and for i = 0, #t do t[i] end which seem just as good to me.
- shakna 6y ago
  You wouldn't end up with this: s:sub(0, #s) You would end up with: s:sub(0, #s - 1) Which demonstrates the off-by-one error.
  - anonymoushn 6y ago
    Can you explain what the intent of the code is and what the error is? It looks like the original code just grabs a substring containing the entire string. If the language used half-open intervals with an exclusive upper bound, the code I posted would also do that. In python, for example, the operation of copying a list can be correctly written l[0:len(l)]. You're more likely to see l[::] or list(l) though. Edit: I think maybe the proposed error that's being avoided is "a user tries to use a closed interval when sub takes a half-open interval." It seems like the opposite error is similarly likely though. Some areas where it's nice to have half-open intervals like using a modulus to restrict a value to an interval or parsing strings don't have such a symmetry. Notably if you're making a binary heap the formulas come out much nicer with 1-indexing than with 0-indexing, but I haven't met any other examples where this is the case.
    - shakna 6y ago
      If the language is using an exclusive upper bound, then it is correcting the mistake of the programmer for specifying a length beyond what the string contains. Lua does do that, so in this theoretical world with 0-indexed strings, it would still work as expected. But it doesn't change the fact that you're not actually specifying the right length - the language is correcting an off-by-one error, which means that the programmer's mental model is probably going to be wrong, and it will bite them when they don't expect it to. That's what off-by-one errors are - a place where the programmer's mental model doesn't actually fit the real world. It is better to not introduce places where they can happen in the first place, rather than to complicate things with edge cases where sometimes it works and sometimes it doesn't.

joan_kode 6y ago

The main problem with that decision is that every discussion having anything to do with Lua always devolves into repetitive bikeshedding about the 1-indexing.

catblast 6y ago
In the context of language design, the arguments for 0-based indexing rise above bikeshedding. https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/E... Sure it may not be the most critical point about language design, but it's not just bikeshedding either. For one thing, it is a language semantics issue rather than plainly syntax issue. I still like Lua, and maybe you don't even agree with Dijkstra's argument, which is also possible to make, but doesn't mean its bikeshedding - which seems to be a totally overused term to basically mean any argument I don't want to have.
- soneca 6y ago
  Are you bikeshedding bikeshedding?? Just kidding, I actually agree with your point that the term is just demonstrate that you don’t want to have a conversation by diminishing the value of anybody having it.
- skrebbel 6y ago
  Fwiw Dijkstra practically invented bikeshedding
  - andi999 6y ago
    bikeshedding considered harmful
- pull_my_finger 6y ago
  Roberto Ierusalimschy makes an interesting point on this in an interview[1] last year. > When we started Lua, the world was different, not everything was C-like. Java and JavaScript did not exist, Python was in an infancy and had a lower than 1.0 version. So there was not this thing when all the languages are supposed to be C-like. C was just one of many syntaxes around. > And the arrays were exactly the same. It’s very funny that most people don’t realize that. There are good things about zero-based arrays as well as one-based arrays. > The fact is that most popular languages today are zero-based because of C. They were kind of inspired by C. And the funny thing is that C doesn’t have indexing. So you can’t say that C indexes arrays from zero, because there is no indexing operation. C has pointer arithmetic, so zero in C is not an index, it’s an offset. And as an offset, it must be a zero — not because it has better mathematical properties or because it’s more natural, whatever. > And all those languages that copied C, they do have indexes and don’t have pointer arithmetic. Java, JavaScript, etc., etc. — none of them have pointer arithmetic. So they just copied the zero, but it’s a completely different operation. They put zero for no reason at all — it’s like a cargo cult. [1] - https://habr.com/en/company/mailru/blog/459466/ https://habr.com/en/company/mailru/blog/459466/

TedDoesntTalk 6y ago

How about this: The empty string and 0 are truthy. Why?

cl3misch 6y ago
Maybe because all variables are `nil` by default, and checking on undeclared variables does not raise an error. So `if foo then ... end` is often used as an existence check, where `foo = 0` should be truthy.
anonymoushn 6y ago
This is probably a good thing, if you don't want to have tickets filed about whether midnight (time of day) is truthy, whether Jan 1, 1970 is truthy, why some type of empty collection is truthy but others are not, etc.
- pansa2 6y ago
  > This is probably a good thing, if you don't want to have tickets filed about whether midnight (time of day) is truthy Agreed. Here is an example of exactly that in Python: https://bugs.python.org/issue13936 https://bugs.python.org/issue13936
DarkWiiPlayer 6y ago
0? Because Lua isn't C. It makes sense for C to treat 0 as falsey, because (void*)0 is Cs way of expressing a nil-value, as well as not having a dedicated boolean value to keep the language simpler. Lua, both has a dedicated nil value and a boolean type, so there's no reason whatsoever to treat zero as falsey, other than the C cargocult. As for empty strings, I really don't see the rationale behind it. An empty string is not nothing. At the very least, it still holds the length-data of 0, so it's conceptually more than just nil and should thus still be truthy.
pansa2 6y ago
If you make the empty string falsy, surely you need to make all empty collections falsy? Python does this, which leads to people checking whether a list is empty using `if l` rather than `if len(l) > 0`. I‘d rather they stuck with “explicit is better than implicit”.

pansa2 6y ago

Yes. There are pros-and-cons of 1-based indexing when considered in isolation. But for Lua, a language that’s commonly used tightly-coupled to C, 1-based indexing is extremely awkward.