I'm glad that's true for you, but my personal experience suggests otherwise. Dijkstra also mentions the Mesa programming language which had all four of the conventions and that anything other than 0-based, half-open leads to errors. See: https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/E...
And for those claiming the world is 1-based, they're full of it. Machining measurement, for example, is ALL 0-based. We're talking a field that has multiple standards for everything and yet they converged on 0-based measurement.
The bigger problem, though, is that I even have to use array-based indexing to iterate something. That's just asking for bugs.
And, my favorite question for people who like 1-based is "Given index and length N, how do I create index-1?"
The answer, of course, is newindex = index - 1 % N.
The question is, of course, a trick because the answer is really: newindex = (index - 1) % N. Don't forget the parentheses or you have a bug.
Yeah, no. I'll stay in my 0-based languages thanks.
Side Note: I have other objections to Lua. The big one being that it's not really compatible between Lua installations. Everybody compiles different modules so Lua becomes neither small nor is it the same language between any two implementations.
> my favorite question for people who like 1-based is "Given index and length N, how do I create index-1?"
Create index-1? I don't think I've ever needed do that. What does come up all the time in practice in both JS and Lua is "how do I assign past the current end of an array?"
In javascript (if you don't use .push) its arr[arr.length] = x
In Lua its arr[#arr + 1] = x
Even having worked with 0-based indexes for over 20 years, I still doubletake reading that javascript code when it’s embedded in complex code before I can convince myself its inserting. But the lua code is intuitive.
Likewise "read the last element in an array":
JS: arr[arr.length - 1]
Lua: arr[#arr]
I much prefer the lua version in all these cases.
And simplicity is important here because the code gets much worse when the array isn't in a local variable, but instead is some complex expression. confabulate(foo.bar.baz[foo.bar.baz.length - 1]); <-- Simple statement. Absolute mess.
Why? "arr[i]" just means "skip i elements and get the next one," which is perfectly intuitive to me. I understand that familiarity is useful, but can you give an intuition for one-indexing that doesn't just appeal to what people are used to?
> the code gets much worse when the array... is some complex expression
Then... don't do that? Rust has "xs.last()", Python has "xs[-1]", and every language has variables. Anyway, even if that code is an "absolute mess" (which is a bit hyperbolic) it's hardly worse than the one-indexed equivalent, which would be
The problem I have is that at a glance this looks correct. Even after decades of programming, I would scroll right past this line in JS without noticing the off-by-1 error here. The only saving grace is that this error will occur consistently.
But yes, I'd take Rust's xs.last() in a heartbeat. Especially because you can assign through it with last_mut().
That said, I agree with others in this thread. People fixate on the 1 based indexing of lua but you get used to it pretty quickly once you spend time with the language. Lua's real problem is its sparse standard library and its weak package ecosystem. If history had run its course slightly differently, I could easily see lua ending up inside web browsers instead of javascript. And becoming much more popular as a result. Lua and javascript are remarkably similar languages semantically.
> The bigger problem, though, is that I even have to use array-based indexing to iterate something. That's just asking for bugs.
You absolutely do not, the standard Lua idiom is to use ipairs. The numeric for loop is there, of course, and the index of the pair (index, value) returned by ipairs will be 1 based. of course.
Iteration isn't why 1-based indexing is bad, it really shows its inadequacy when doing interval maths. I make abstract syntax trees in Lua, and a node in that tree with zero width at the 4th position is { left = 4, right = 3 } which is... awful.
Except that your children are >1460 days old and >2190 days old.
You count age from 0 in most English-speaking countries (there are places where "1 year old" means 0<=x<365 days old). When you are less than 1, we count with smaller units.
So, my N=3 sample (you and your two children) says we use 0-based counting.
Round(age)? So, they became one year old at 180 days? I doubt that.
And, as I pointed out, there are folks in the world who call their newborn "one year old". And they consider themselves quite sane, thanks.
They count from 1. We count from zero.
Back to the original issue ...
The problem you now have in programming is that it isn't enough that basing from 1 is equivalent. The vast majority of the programming world has converged on 0-based. 1-based has to demonstrate that it is better in order to compensate for the friction of existing in a 0-based world.
And 1-based simply isn't demonstrably better even if I concede that it isn't worse (and I do not concede that).
And for those claiming the world is 1-based, they're full of it. Machining measurement, for example, is ALL 0-based. We're talking a field that has multiple standards for everything and yet they converged on 0-based measurement.
The bigger problem, though, is that I even have to use array-based indexing to iterate something. That's just asking for bugs.
And, my favorite question for people who like 1-based is "Given index and length N, how do I create index-1?"
The answer, of course, is newindex = index - 1 % N.
The question is, of course, a trick because the answer is really: newindex = (index - 1) % N. Don't forget the parentheses or you have a bug.
Yeah, no. I'll stay in my 0-based languages thanks.
Side Note: I have other objections to Lua. The big one being that it's not really compatible between Lua installations. Everybody compiles different modules so Lua becomes neither small nor is it the same language between any two implementations.