In the context of language design, the arguments for 0-based indexing rise above bikeshedding. https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/E...

Sure it may not be the most critical point about language design, but it's not just bikeshedding either. For one thing, it is a language semantics issue rather than plainly syntax issue.

I still like Lua, and maybe you don't even agree with Dijkstra's argument, which is also possible to make, but doesn't mean its bikeshedding - which seems to be a totally overused term to basically mean any argument I don't want to have.

Roberto Ierusalimschy makes an interesting point on this in an interview[1] last year.

> When we started Lua, the world was different, not everything was C-like. Java and JavaScript did not exist, Python was in an infancy and had a lower than 1.0 version. So there was not this thing when all the languages are supposed to be C-like. C was just one of many syntaxes around.

> And the arrays were exactly the same. It’s very funny that most people don’t realize that. There are good things about zero-based arrays as well as one-based arrays.

> The fact is that most popular languages today are zero-based because of C. They were kind of inspired by C. And the funny thing is that C doesn’t have indexing. So you can’t say that C indexes arrays from zero, because there is no indexing operation. C has pointer arithmetic, so zero in C is not an index, it’s an offset. And as an offset, it must be a zero — not because it has better mathematical properties or because it’s more natural, whatever.

> And all those languages that copied C, they do have indexes and don’t have pointer arithmetic. Java, JavaScript, etc., etc. — none of them have pointer arithmetic. So they just copied the zero, but it’s a completely different operation. They put zero for no reason at all — it’s like a cargo cult.

[1] - https://habr.com/en/company/mailru/blog/459466/

I'm confused. Lisp does 0-based indexing. Lisp predates C and C-like languages by decades.

They don't say that C was the first. The claim is that C's influence was responsible for the proliferation.

(Bit of a tangent: Lisp predates C by at most 2 years if you count McCarthy's original 1960 paper, but afaict their respective implementations both got their first public distribution in 1962. Of course, Lisp was set to gain momentum from that time until the AI winter, while C was practically confined to UNIX until the 80s...)

Historically, everyone who studied computing seriously learned assembly language, and it was much more widely used.

In early computing, assembly language saw a lot of use. The navigation program that sent the Apollo mission to the Moon was written in assembly language. During the micro-computer boom, which echoed the history of big iron boom, a lot of applications and systems were written in assembly language again. Most commercial video games for 8 bit micros were written in assembly language. The famous WordPerfect word processor for the IBM PC was assembly language. The VMS operating system: assembly language.

C became easily popular because it gave a nice notation, and a sprinkling of type, to assembly language memory manipulation concepts that most professional programmers already knew how to use.

C wasn't from 1972? Basically a decade later?

Oof yes, that's correct. The manual is dated 12 June 1972, which seems to be the release date.

Lisp isn't the reason modern-day languages are all offset-indexed though; that's Cs fault

Are you bikeshedding bikeshedding??

Just kidding, I actually agree with your point that the term is just demonstrate that you don’t want to have a conversation by diminishing the value of anybody having it.

Fwiw Dijkstra practically invented bikeshedding

bikeshedding considered harmful

I think the main problem with 1-indexing is that it makes some formulas that depend on the length of an array more complicated. Not a huge problem, but it's kind of annoying.

It replaces the standard [0,len()) with an [1,len()], though, which correspondingly makes other tasks easier. Plus it matches normal mathematical vector indexing.

In the end, in a language where you aren't doing pointer arithmetic, the sides are pretty even. We just tend to side with tradition, because it's easier to.

I found it uncomfortable when drawing on screen:

   y = margin + (i - 1) * lineheight

  y = 1 + ...

if y is 1-based too (which feels even more uncomfortable). But it would be nice to have such functions out if the box:

  canvas.linear_index(x, y, stride)
  vbox.y1_for(margin, spacing, height, i)
  vbox.y2_for(margin, spacing, height, i)

And then you have "integer at the center of a pixel" vs "integer at the top-left of a pixel" differences, which should be taken into account by these functions too. Stroke 1: y+0.5, y+height-1. Stroke 2: y+1, y+height-2. Fill: y, y+height.

Pixel geometry is hard on its own.

Off by ones happen with 0-based too (to me at least, at "write the new codez" stage). What languages are really missing is some stdlib for hiding these calculations under easily understandable names like nthfromend, nfromto, revidx, last, etc. Too much of n-1, n-i-1, -i-1, b-a+1, <, <= to maintain in correct ranges either way.

0/1-based are simply two degenerate around-off-by-one cases of working at general n-based offset, since both 0 and 1 are the most common results of off-by-one.