Except that's counting, not indexing. It doesn't make sense to compare the two. It's more akin to the "is the first floor the ground floor or the one above it"-debate.

Perhaps you mean it's displacing not indexing?

Counting is indexing!

What is it that you do when you count items in a set? You put them into correspondence with the natural numbers, indicating each one as 1, 2, 3, ... The last integer is the count.

Yes, it is related to the "is the first floor ground, or the one above it"; and it's clear that some programming languages take their cue from stairs and elevators.

Nobody ever has to calculate "what is the floor twice as high as this one?" Moreover, people are unfazed by 13 missing.

(I haven't seen a language that omits 13 from indexing, fortunately.)

Since we can probably agree that you're not indexing distances or other units of measurement (you can make a piece of string of length sprt(2) centimeters or other irrational lengths!), let's skip the terminology argument. That wasn't my point.

Is skipping the 13th floor a US thing? I don't recall ever seeing it in the UK or Germany.

Yes, in the US, you will almost never see a 13th floor.

It's ironic, though, that most languages report 1-based source code line numbers in their error diagnostics, regardless of how they handle indexing. So that does say something.

And their documentation has section numbers like 1.1, 1.2, ... 5.3.3.

The current Julia version is 0.4.5 =).

Distance doesn't use indexing at all, because measures are not indexes, so it doesn't make sense to say "if distances used 1-based indexing".

OTOH, for something physical that actually is indexing, or at least closely analogous to it, we could ask "what if principal quantum numbers used 1-based indexing". But, then, the answer would be "things would look exactly like they do now, because it already does."

But that's the point, once you think of indexes as distance things make much more sense.

The index is the distance from the first element. Thus, the third element is two elements away from the first, thus it has index 2.

I think the only reason zero-based indexing is not the standard everywhere is because some people (usually non-programmers) have a problem with the idea that the fifth element has index four.

I am suggesting that this is a linguistic problem that has messed up programming.

Consequently, when those people do music, they have to accept that something called an octave has seven notes, and inverting an interval is based on the "rule of nine", thanks to the way they defined intervals as one based.

Distances can be quantized. If you're designing something in your CAD tool, you can set a grid to, say 1cm, and never place anything on a fraction of a cm. The coordinates of points in the design are then de facto addresses.

Indices can be regarded as measures. We speak about an array having a "size" or "length": that is measurement language. Something is "3 words wide": ditto.

A given record in a file can be 25 words from the beginning, or 100 bytes, or 800 bits. All of these tell us how much storage immediately precedes that record and we can easily convert among them.

If indices support calculation, they should be displacements, and displacements should originate at zero.

Indices not intended for calculation (beyond simple successor/predecessor, perhaps) can place items into correspondence with any ordered set: natural numbers, letters of the alphabet, and so on. This is where we can get away with 1 based.

Indices not intented for any calculation whatsoever can use a set: like associating character strings with objects via an "associative" array or whatever.