This indeed is not Algol (or rather C) heritage, but Fortran heritage, not memory offsets but indices in mathematical formulae. This is why R and Julia also have 1-based indexing.

Pascal. Modula-2. BASIC. Hell, Logo.

Lately, yes, Julia and R.

Lots of systems I grew up with were 1-indexed and there's nothing wrong with it. In the context of history, C is the anomaly.

I learned the Wirth languages first (and then later did a lot of programming in MOO, a prototype OO 1-indexed scripting language). Because of that early experience I still slip up and make off by 1 errors occasionally w/ 0 indexed languages.

(Actually both Modula-2 and Ada aren't strictly 1 indexed since you can redefine the indexing range.)

It's funny how orthodoxies grow.

In fact zero-based has shown some undeniable advantages over one-based. I couldn't explain it better than Dijkstra's famous essay: http://www.cs.utexas.edu/~EWD/ewd08xx/EWD831.PDF

It's fine, I can see the advantages. I just think it's a weird level of blindness to act like 1 indexing is some sort of aberration. It's really not. It's actually quite friendly for new or casual programmers, for one.

I think the objection is not so much blindness as the idea that professional tools should not generally be tailored to the needs of new or casual users at the expense of experienced users.

Is there any actual evidence that new programmers really find this hard? Python is renowned for being beginner friendly and I've never heard of anyone suggesting it was remotely a problem.

There are only a few languages that are purely for beginners (LOGO and BASIC?) so it's a high cost to annoy experienced programmers for something that probably isn't a big deal anyway.

I think the claim might harken back to the days when programming was a new thing and mathematicians,physicists,etc were the ones most often getting started at it, if they had by training gotten used to 1 based indexing in mathematics it was probably a bit of a pain to adapt (and why R and Matlab,etc use 1-based indexing).

Thus, 1 probably wasn't "easier", it just adhered to an existing orthodoxy that "beginners" came from at the time.

> Lots of systems I grew up with were 1-indexed and there's nothing wrong with it. In the context of history, C is the anomaly.

The problem is that Lua is effectively an embedded language for C.

If Lua never interacted with C, 1-based indexing would merely be a weird quirk. Because you are constantly shifting across the C/Lua barrier, 1-based indices becomes a disaster.

Pascal, frankly, allowed to index arrays by any enumerable type; you could use Natural (1-based), or could use 0..whatever. Same with Modula-2; writing it, I freely used 0-based indexing when I wanted to interact with hardware where it made sense, and 1-based indexes when I wanted to implement some math formula.

As I understand it Julia changed course and is attempting to support arbitrary index ranges, a feature which Fortran enjoys. (I'm not clear on the details as I don't use either of them.)

There was no change of course. Julia's AbstractArray interface requirements are just agnostic about array start indices. we have packages (e.g. OffsetArrays.jl) for arbitrary index ranges and that has existed for a long time.

If anything, the only significant change is that the community is becoming more and more convinced that offset array support is a bit of a footgun and makes it easy for bugs to sneak into generic code.

Let’s hope that they don’t also replicate ISO Fortran’s design flaws with lower array bounds, which contain enough pitfalls and portability problems that I don’t recommend their use.

I haven't used either language much myself and I thought the feature looked brilliant so I'd be very curious to know what sort of issues you ran into in practice.

And MATLAB. Doesn't make it any better that other languages have the same mistake.

Does it count as 0-indexing when your 0 is a floating point number?

Actually in JS array indexing is same as property indexing right? So it's actually looking up the string '0', as in arr['0']

Huh. I always thought that JS objects supported string and number keys separately, like lua. Nope!

  [Documents]$ cat test.js
  let testArray = [];
  testArray[0] = "foo";
  testArray["0"] = "bar";
  console.log(testArray[0]);
  console.log(testArray["0"]);
  [Documents]$ jsc test.js
  bar bar
  [Documents]$

Lua supports even functions and objects as keys:

  function f1() end
  function f2() end
  local m1 = {}
  local m2 = {}
  local obj = {
      [f1] = 1,
      [f2] = 2,
      [m1] = 3,
      [m2] = 4,
  }
  print(obj[f1], obj[f2], obj[m1], obj[m2], obj[{}])

Functions as keys is handy when implementing a quick pub/sub.

They do, but strings that are numbers will be reinterpreted as numbers.

[edit]

  let testArray = [];
  testArray[0] = "foo";
  testArray["0"] = "bar";
  testArray["00"] = "baz";
  console.log(testArray[0]);
  console.log(testArray["0"]);
  console.log(testArray["00"]);

That example only shows the opposite of what it sounds like you’re saying, although you could be getting at a few different true things. Anyway:

- Every property access in JavaScript is semantically coerced to a string (or a symbol, as of ES6). All property keys are semantically either strings or symbols.

- Property names that are the ToString() of a 31-bit unsigned integer are considered indexes for the purposes of the following two behaviours:

- For arrays, indexes are the elements of the array. They’re the properties that can affect its `length` and are acted on by array methods.

- Indexes are ordered in numeric order before other properties. Other properties are in creation order. (In some even nicher cases, property order is implementation-defined.)

  { let a = {}; a['1'] = 5; a['0'] = 6; Object.keys(a) }
  // ['0', '1']

  { let a = {}; a['1'] = 5; a['00'] = 6; Object.keys(a) }
  // ['1', '00']

There's nothing wrong with 1-based indexing. The only reason it seems wrong to you is because you're familiar with 0-based, not because it's inherently worse.

I'll refer you to Dijkstra's "Why numbering should start at zero": https://www.cs.utexas.edu/~EWD/transcriptions/EWD08xx/EWD831...

If a language has a well-designed collections library (think Smalltalk and derivatives, not C++'s STL), the difference between 1 and 0-based indexing is hard even to notice, much less lead to "less elegant" code. Between Stream and Collection subclasses, the API is rich enough that using indexes is reserved for very low-level operations that you seldom use in non-FFI, non-VM code.

What you say is true for languages that don't have collections, real arrays, or vectors, only memory ranges. This is the case of C, but not Fortran, Pascal, or Ada. So yeah, if all you have is a hammer, you'd better use 0-based nails; hopefully, though, we'll allow for non-hammer tools in popular toolboxes sometime this century.

If you can't deal with off-by-one errors, you're not a programmer.

But with Lua all those errors are now off by two

Or 0. Lua is in superposition, ready for the quantum computing age.

Except for Date.