3 ms·

Please cite an example where this is superior to a 0-based-index example. Just saying "it's a good thing" won't fucking fly around here.

Dylan16807 13y ago
I thought I explained myself, especially with my second comment, but sure I'll go over it again in detail. Premise 1: Accessing a null index is a logically invalid operation. Premise 2: Silent invalid operations are bad. Premise 3: If a null has a special representation that the hardware understands to be invalid, it can trap or set a flag or otherwise not be silent. Conclusion: Null indexes that are architecturally invalid to use are a good thing, because you can catch bugs involving their use immediately. Edit: made terms clearer
- eridius 13y ago
  Passing 0 as the index into an indexing operation is not even remotely "accessing a null value". Also, believe it or not, on various machines and OS's it's legal to map address 0. Edit: Your edit makes even less sense. There is no such thing as a "null index", much less an operation to "access a null index".
  - Dylan16807 13y ago
    >There is no such thing as a "null index", Would you rather I write "index that is 0 in a world where indexes start at 1" over and over? I am willing to do that if it helps make the conversation smoother. >much less an operation to "access a null index". foo_array[0]; //operation to do an access with a null index >Also, believe it or not, on various machines and OS's it's legal to map address 0. Which is a bad thing. You get a couple extra variable slots in exchange for thousands of privilege-escalation bugs that could instead be crash bugs.
    - lectrick 13y ago
      How in the hell does "accidentally" accessing the first element of an array (by "accidentally" passing 0 to an array in a language that has 0-based indexing) result in "privilege escalation errors"? That's just "shitty programming". For that matter, how does a 1-based indexing language NOT result in far more "off by one" errors which would include the kind of errors commonly known as "buffer overflow" errors?
      - Dylan16807 13y ago
        In most cases indexing doesn't affect safety, the privilege stuff was related to what eridius was talking about with physical addresses. I don't think either one creates more off-by-one errors in people used to it.
- lectrick 13y ago
  Null is NOT the same as "zero" Ruby has "nil", and 0. They are not the same, and should not be considered the same. Would you say that accessing coordinate 0,0 is a "logically invalid operation"? What is an array but a 1 dimensional coordinate system? Are you suggesting that accessing an array via an uninitialized parameter will show up as a runtime error because of 1-based indexing? That only happens if your language initializes values to 0. Ruby initializes everything to nil, not 0, and yes, indexing by nil will fail. Perhaps I'm not seeing your problem or solution because Ruby doesn't even have the kind of problem that is solved by a 1-based array index. See: the Sapir-Whorf Hypothesis http://en.wikipedia.org/wiki/Linguistic_relativity http://en.wikipedia.org/wiki/Linguistic_relativity , your thinking may be suffering due to the language you are typically working in.
  - Dylan16807 13y ago
    >Would you say that accessing coordinate 0,0 is a "logically invalid operation"? If you have a matrix that starts at cell 1,1 then trying to access 0,0 is absolutely a logically invalid operation. I'm not saying that 0-indexing is illogical, I'm saying that dereferencing null/nil is illogical. As for the rest of your post, the scenario eridius came up with is pretty weird, at this point I'm just going to shrug and give up on analysis.
- IanCal 13y ago
  Premise 4: Your type system can't tell the difference between "null" and 0. Adding 4 and null also makes no sense, yet 4 + 0 is perfectly fine. > Conclusion: Null indexes that are architecturally invalid to use are a good thing, because you can catch bugs involving their use immediately. Recommendation: Have a good type system. >>> a = [1] >>> a[None] Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: list indices must be integers, not NoneType

Dylan16807 13y ago

I thought I explained myself, especially with my second comment, but sure I'll go over it again in detail. Premise 1: Accessing a null index is a logically invalid operation. Premise 2: Silent invalid operations are bad. Premise 3: If a null has a special representation that the hardware understands to be invalid, it can trap or set a flag or otherwise not be silent. Conclusion: Null indexes that are architecturally invalid to use are a good thing, because you can catch bugs involving their use immediately. Edit: made terms clearer

eridius 13y ago
Passing 0 as the index into an indexing operation is not even remotely "accessing a null value". Also, believe it or not, on various machines and OS's it's legal to map address 0. Edit: Your edit makes even less sense. There is no such thing as a "null index", much less an operation to "access a null index".
- Dylan16807 13y ago
  >There is no such thing as a "null index", Would you rather I write "index that is 0 in a world where indexes start at 1" over and over? I am willing to do that if it helps make the conversation smoother. >much less an operation to "access a null index". foo_array[0]; //operation to do an access with a null index >Also, believe it or not, on various machines and OS's it's legal to map address 0. Which is a bad thing. You get a couple extra variable slots in exchange for thousands of privilege-escalation bugs that could instead be crash bugs.
  - lectrick 13y ago
    How in the hell does "accidentally" accessing the first element of an array (by "accidentally" passing 0 to an array in a language that has 0-based indexing) result in "privilege escalation errors"? That's just "shitty programming". For that matter, how does a 1-based indexing language NOT result in far more "off by one" errors which would include the kind of errors commonly known as "buffer overflow" errors?
    - Dylan16807 13y ago
      In most cases indexing doesn't affect safety, the privilege stuff was related to what eridius was talking about with physical addresses. I don't think either one creates more off-by-one errors in people used to it.
lectrick 13y ago
Null is NOT the same as "zero" Ruby has "nil", and 0. They are not the same, and should not be considered the same. Would you say that accessing coordinate 0,0 is a "logically invalid operation"? What is an array but a 1 dimensional coordinate system? Are you suggesting that accessing an array via an uninitialized parameter will show up as a runtime error because of 1-based indexing? That only happens if your language initializes values to 0. Ruby initializes everything to nil, not 0, and yes, indexing by nil will fail. Perhaps I'm not seeing your problem or solution because Ruby doesn't even have the kind of problem that is solved by a 1-based array index. See: the Sapir-Whorf Hypothesis http://en.wikipedia.org/wiki/Linguistic_relativity http://en.wikipedia.org/wiki/Linguistic_relativity , your thinking may be suffering due to the language you are typically working in.
- Dylan16807 13y ago
  >Would you say that accessing coordinate 0,0 is a "logically invalid operation"? If you have a matrix that starts at cell 1,1 then trying to access 0,0 is absolutely a logically invalid operation. I'm not saying that 0-indexing is illogical, I'm saying that dereferencing null/nil is illogical. As for the rest of your post, the scenario eridius came up with is pretty weird, at this point I'm just going to shrug and give up on analysis.
IanCal 13y ago
Premise 4: Your type system can't tell the difference between "null" and 0. Adding 4 and null also makes no sense, yet 4 + 0 is perfectly fine. > Conclusion: Null indexes that are architecturally invalid to use are a good thing, because you can catch bugs involving their use immediately. Recommendation: Have a good type system. >>> a = [1] >>> a[None] Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: list indices must be integers, not NoneType