> 1-based indexing is superior to 0-based indexing.
this breaks the identity `arr[idx] == *(arr + idx)`. as a c++ (and sometimes c) dev, I tend to consider "index" and "offset" to be functionally equivalent. hard pass.
> If you use spaces to indent code, or in any way rely on a fixed width font to "line things up", you have a fundamental misunderstanding.
I find "lining things up" to be pretty helpful for spotting mistakes in tedious code (eg, matrix initialization) where you have a bunch of similar lines of code in a row. am I missing your point, or do you just not agree this is useful?
> this breaks the identity `arr[idx] == (arr + idx)`. as a c++ (and sometimes c) dev, I tend to consider "index" and "offset" to be functionally equivalent. hard pass.
And I think that's the problem. Programmers have collectively conflated the concept of "offset from the address" and "position in the list" as the same concept, and they're not the same thing. Both concepts have their uses but they're separate distinct concepts. C and C++ don't index* a list, they simply offset it, and too many other languages that don't care about in-memory addresses or offsets have carried the concept from offset over to index erroneously.
I can see how in a higher-level language it might make sense to use 1-based indices. this is, after all, how humans typically count. I just don't agree with it as a general statement over all programming languages. in low-level contexts where you are working directly with memory, it is quite natural for indices (or idx * element_size) to be equivalent to offsets.
Right. But while I'm just trying to do my work as a programmer, which of those two identities is going to be easier to work with, reason about, and come out of it with correct code? Hint: It doesn't have a "1" in it.
Your identity perfectly illustrates why 1-based arrays are worse rather than better.
That's true for C/C++, but in most languages used today where we don't use pointers, where is the advantage?
I'm hundreds of times more likely to have to write lastElement = array[array.length - 1] (there's the 1 again!) than I am to have to reason about the equivalent pointer arithmetic.
Even in a language without pointers, in a multidimensional array you can index the data one-dimensionally by array[index0 + N * index1] with 0-based indexing, as opposed to array[index0 + N * (index1-1)]. Where N is the length of the inner nested array.
And for that matter all algorithms for which zero-based indexing makes more sense are simpler, such as working with polynomials and expansions where the zeroth power is included in the expansion.
Having said that, I too prefer 1-based indexing because the list of algorithms that are written more cleanly (i.e. without constantly causing bugs when you implement them) is far larger for me personally, including all of linear algebra and related numerical methods.
In a language that has one-based indexing, can you treat a multidimensional array as one-dimensional? Or will it give you an array index out of bounds error?
That is, are there any languages that are both one-based, and will let you do that trick?
You would need it to support one-dimensional views (unless your data is just stored as one-dimensional to begin with). Certainly matlab and Julia do. Don't know of any new 1-based languages either way.
> 1-based indexing is superior to 0-based indexing.
this breaks the identity `arr[idx] == *(arr + idx)`. as a c++ (and sometimes c) dev, I tend to consider "index" and "offset" to be functionally equivalent. hard pass.
> If you use spaces to indent code, or in any way rely on a fixed width font to "line things up", you have a fundamental misunderstanding.
I find "lining things up" to be pretty helpful for spotting mistakes in tedious code (eg, matrix initialization) where you have a bunch of similar lines of code in a row. am I missing your point, or do you just not agree this is useful?