Hacker News new | past | comments | ask | show | jobs | submit login

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




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 , your thinking may be suffering due to the language you are typically working in.


>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.


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


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".


>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.


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?


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: