The ground floor in lifts isn't "1", it is "G". Same thing.

Country dependent. Like there are 1-based indexing languages (Lua, Matlab, et al)

And others like Pascal linage (Pascal, Object Pascal, Extended Pascal, Modula-2, Ada, Oberon,...), that have flexible bounds, they can be whatever numeric subranges we feel like using, or enumeration values.

Actually some lifts don't start with G but -2, because basement exists.

Not in Lua.

Most languages have abstractions for iterating over an array so that you don’t need to use 0 or length-1 these days

Because the math books are the ones being weird. https://www.cs.utexas.edu/~EWD/transcriptions/EWD08xx/EWD831...

Maths books aren't being weird. They are counting in a way most people learn to count. One apple, two apples, three apples. You don't start zeroth apple, one apple, two apples, then respond the set of apple contains three apples.

But computers are not actually counting array elements, it's more accurate to compare array indexing with distance measurement. The pointer (memory address) puts you at the start of the array, so the first element is right there under your feet (i.e. index 0). The other elements are found by measuring how far away from the start they are:

  element_position = start + index*element_size

> But computers are not actually counting array elements

Sure. But from most general to least general, it goes:

Counting on fingers >>>> Math Equations >> Computer algorithms

The more general ones influence the less general ones because that's where most people start.

I believe it’s a practicality to simplify pointer arithmetic

Yes but why does no one talk here about fighting the 0 indices. Or how they are switching to Lua, because 0 indices are hard?

Am I the only person that remembers how hard it was to wrap your head around numbers starting at 0, rather than 1?

I find indices starting from zero much easier. Especially when index/pointer arithmetic is involved like converting between pixel or voxel indices and coordinates, or indexing in ring buffers. 1-based indexing is one of the reasons I eventuallz abandoned Mathematica, because it got way too cumbersome.

So the reason why you don't see many people fighting 0-indexing is because they actually prefer it.

> 0 indices are hard?

I started out with BASIC and Fortran, which use 1 based indices. Going to C was a small bump in the road getting used to that, and then it's Fortran which is the oddball.

Most oldschool BASIC dialects (including the original Dartmouth IIRC) use 0-based indices, though. It's the worst of both worlds, where something like:

  DIM a(10)

actually declares an array of 11 elements, with indices from 0 to 10 inclusive.

I believe it was QBASIC that first borrowed the ability to define ranges explicitly from Pascal, so that we could do:

  DIM a(1 TO 10)

etc to avoid the "zero element tax"

Interesting path. I went Basic, and Pascal and then C in college. Honestly it was such a mind twist.

Yes, I think you are. The challenges people describe with Rust look more difficult than remembering to start from 0 instead of 1…

I don't think so. One based numbering is barring few particular (spoken) languages the default. You have to had to change your counting strategies when going from regular world to 0 based indices.

Maybe you had the luck of learning 0 based language first. Then most of them were a smooth ride.

My point is you forgot how hard it is because it's now muscle memory (if you need a recap of the difficulty learn a program with arbitrary array indexing and set you first array index to something exciting like 5 or -6). It also means if you are "fighting the borrow checker" you are still at pre-"muscle memory" stage of learning Rust.

> Maybe you had the luck of learning 0 based language first. Then most of them were a smooth ride.

Given most languages since at least C have 0-based indexing... I would think most engineers picked it up early? I recall reading The C Programming Language 20 years ago, reading the reason and just following what it says. I don't think it's as complex as the descriptions people put forward of "fighting the borrow checker." One is "mentally add/subtract 1" and another is "gain a deep understanding of how memory management works in Rust." I know which one I'm going to find more challenging when I get round to trying to learn Rust...

> Given most languages since at least C have 0-based indexing.

As I mentioned I started Basic on C64, and schools curriculum was in Pascal. I didn't learn about C until I got to college.

> One is "mentally add/subtract 1" and another is "gain a deep understanding of how memory management works in Rust."

In practice they are, you start writing code. At first you trip on your feet, read stuff carefully, then try again until you succeed.

Then one day, you wake up and realize I know 0 indices and/or borrow checker. You don't know how you know, you just know you don't make those mistakes anymore.

I was Basic (on C64) -> assembly -> Pascal -> C, more or less. 0-based indexing wasn't too bad for me, except when it came to for loops.

    for (i=0; i<length; i++)

I eventually just memorized that pattern, but stumbled every time any part of it changed. I had to rethink the whole logic every time to figure out < vs <= and length vs length-1, and usually ended up getting an answer that was both confident and wrong.

The borrow checks feels similar but different. It feels like it has more "levels" to it. Initially, it came naturally to me and I wondered what all the fuss was about. I was fighting iterators and into, not the borrow checker. I just had to mentally keep track of what owned my data and it all felt pretty obvious.

Then I started working on things that didn't fit into my naive mental model, and it became a constant fight.

So overall, a similar experience to 0-based indexing, yes. (Except I still don't "just know" the trickier bits of the borrow checker yet, so I don't know what comes next.)

I literally just described my process, so I don’t get how you got to “you don’t know how you know” because… well… I just told you.

Also, there’s a huge difference between beginners not understanding 0-based indexing and experienced C++ engineers describing the challenges understanding Rust’s unique features. I mean, Jesus Christ, we’re commenting on a thread here of experienced engineers commenting on how challenging it can be! I really don’t know what else to say.

> Also, there’s a huge difference between beginners not understanding 0-based indexing and experienced C++ engineers describing the challenges understanding Rust’s unique features

Keep in mind I wasn't new to programming at that point. I was programming in C64 basic for 3 years and Pascal for 3 as well. For hobby of course, and not fully.

Zero indexes aren't simple, they are intertwined everywhere but they are easy - as in familiar.

What experienced C++ devs in Rust are not much different than experienced Pascal devs in C. Lost. And having to rethread semi-familiar grounds.

---

And I described you my own. I don't fight the borrow checker. I just intuitively know how it works and what to avoid.

If you think just subtracting one or adding one is enough, there should be an easy enough way to test if it is. In Veritasium video they mention that having glasses that turn your vision upside down will cause confusion at first, but you will get used to them quickly.

What you could do is take a language that has arbitrary starting index value and set it to something weird. Like 42 or -5. Then rewrite your programs. See how many off by 41 errors you make. Then once you no longer make mistakes with it. Go back to 0 indexes.

> What you could do is take a language that has arbitrary starting index value and set it to something weird. Like 42 or -5. Then rewrite your programs. See how many off by 41 errors you make. Then once you no longer make mistakes with it. Go back to 0 indexes.

Do you need me to comment on the difference between 0 and 42?

No.

But you need to see with eyes of a newbie. I mean what is the problem here, you did say it's just adding or subtracting a number whether it's 0, 1, -1 or 42? Should be trivial, right?

My guess while the change of indices is simple (altering ranges by a constant), it's going to be hard (requiring constant mental effort until it's internalized).

> I mean what is the problem here, you did say it's just adding or subtracting a number whether it's 0, 1, -1 or 42? Should be trivial, right?

Apparently I do need to comment but I don't think any human on earth has the words to convince you that, as a human, adding/subtracting by 1 is a billion times easier to understand than adding/subtracting 42.

> adding/subtracting by 1 is a billion times easier to understand than adding/subtracting 42.

Ok, then add start your indices with something else 1 or 2, -1 would be best but probably not well supported. Whatever you aren't used to.

Also why is substracting a small number such a problem? I never found adding/substracting 1, much more difficult than 42. It's just math.

> Also why is substracting a small number such a problem? I never found adding/substracting 1, much more difficult than 42. It's just math.

If the answer to your question is not self-evident, then I don't know of any words that will convince you.

For languages with 0-based array element numbering, say what the numbers are: they're offsets. 0-based arrays have offsets, 1-based arrays have indices.

I sometimes work on creating my own programming language (because there aren't enough of those already) and one of the things I want to do in it is 1-based indexing. Just so I can do:

  (defvar names (Vector String)
    #("Alex" "Kim" "Robin" "Sam"))
  (elt names 1)

...and get "Alex" instead of "Kim".

Or take a lesson from languages where this isn't a religious question and do

    (defvar names (Vector String)
      #("Alex" "Kim" "Robin" "Sam"))
    (first names)

or if being flexible,

    (defvar names (Vector String)
      #("Alex" "Kim" "Robin" "Sam"))
    (elt names (lowbound names))

Bonus points for adding a macro or function, to make the second form available as first as well.