The main problem with that decision is that every discussion having anything to do with Lua always devolves into repetitive bikeshedding about the 1-indexing.

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.

Once you get used to it, it does help prevent a whole bunch of off by one errors though, as you don't need math when grabbing a range.

Like a string will always be:

    s:sub(1, #s)

And a sequence table will always be:

    for i = 1, #t do
      t[i]
    end

I disagree. Particularly when parsing strings, it's useful if the upper bound of one substring is the lower bound of a nonoverlapping substring immediately after. For example, here's a routine to split a string into the part before the first dot and the part after:

  function split_dot(s)
    local idx = s:find(".", 1, true)
    if not idx then return s end
    return s:sub(1,idx-1), s:sub(idx+1)
  end

It may come as a surprise that one should use a difference of 2 to skip over one character!

In a language that used the half-open interval convention we would end up with:

  s:sub(0, #s)

and

  for i = 0, #t do
    t[i]
  end

which seem just as good to me.

> It may come as a surprise that one should use a difference of 2 to skip over one character!

On the contrary; unless you're very used to offset-indexing, it seems more natural to start at the next element for the next substring, or the 2nd next element when skipping one.

You wouldn't end up with this:

     s:sub(0, #s)

You would end up with:

     s:sub(0, #s - 1)

Which demonstrates the off-by-one error.

Can you explain what the intent of the code is and what the error is? It looks like the original code just grabs a substring containing the entire string. If the language used half-open intervals with an exclusive upper bound, the code I posted would also do that.

In python, for example, the operation of copying a list can be correctly written l[0:len(l)]. You're more likely to see l[::] or list(l) though.

Edit: I think maybe the proposed error that's being avoided is "a user tries to use a closed interval when sub takes a half-open interval." It seems like the opposite error is similarly likely though. Some areas where it's nice to have half-open intervals like using a modulus to restrict a value to an interval or parsing strings don't have such a symmetry.

Notably if you're making a binary heap the formulas come out much nicer with 1-indexing than with 0-indexing, but I haven't met any other examples where this is the case.

If the language is using an exclusive upper bound, then it is correcting the mistake of the programmer for specifying a length beyond what the string contains.

Lua does do that, so in this theoretical world with 0-indexed strings, it would still work as expected.

But it doesn't change the fact that you're not actually specifying the right length - the language is correcting an off-by-one error, which means that the programmer's mental model is probably going to be wrong, and it will bite them when they don't expect it to.

That's what off-by-one errors are - a place where the programmer's mental model doesn't actually fit the real world. It is better to not introduce places where they can happen in the first place, rather than to complicate things with edge cases where sometimes it works and sometimes it doesn't.

> If the language is using an exclusive upper bound, then it is correcting the mistake of the programmer for specifying a length beyond what the string contains.

No, it's not-correcting the not-error of the programmer specifying the correct upper bound using the half-open-interval model, a common mathematical model of range specification that has lots of useful properties.

It's useful, if you are writing ternary search (over integers) or some such thing concerned with intervals, to be able to compute the length as hi-lo, and to be able to use hi<lo to check whether an interval is malformed, rather than writing hi-lo+1 and hi+1<lo. In the example about using modulo to place all integers into some interval upthread, most programming languages let you write (n-lo)%(hi-lo)+lo, but in Lua you should maybe write (n-lo)%(hi+1-lo)+lo. It doesn't seem like I am getting less likely to make errors here!

That would be strange, in Ruby

    s = "foo"
    s.length
    #=> 3
    s[0, s.length]
    #=> "foo"

Same in JavaScript

    s.slice(0, s.length)

and Python

    s[0:len(s)]

Yet, none of those are consistent with that on non-string objects:

To get the last object of an array in JS is:

    arr = [1, 2, 3]
    arr[arr.length - 1]

To get the last object of an array in Python is:

    arr = [1, 2, 3]
    arr[len(arr) - 1]

To get the last object of an array in Lua is:

    arr = {1, 2, 3}
    arr[#arr]

There is a difference between order and offset, both consistent and makes sense. We use both models in everyday life. Examples of offset are ruler (marks 0, 1, ...), time offset (this hour, next hour, ..), age (newborn, one year, two years), count (last, last but one). That's reflected in our languages [1].

> non-string objects

There is no difference between array and string access in ruby, python, js.

There are better ways to access last element (python, ruby):

    >>> arr[-1] # meaning first element from back (1-indexing!)
    3

I mentioned your comment is wrong. I do not know why you are turning it into 0-indexing vs 1-indexing, looks like changing topic for me.

[1] https://en.wikipedia.org/wiki/Comparison_of_programming_lang...

> I mentioned your comment is wrong. I do not know why you are turning it into 0-indexing vs 1-indexing, looks like changing topic for me.

... That's exactly where this topic started:

> 1-index kept throwing me off though

---

> There is no difference between array and string access in ruby, python, js.

There's no difference in Lua either:

    s:sub(1, 1)
    tbl:select(1, 1)

But it doesn't use offset, and I find that more useful for preventing off-by-one errors.

I am to used to 0-indexing to judge. If it is not clear already - I am not going to participate in who is better. My thread is

>>>> a string will always be:

    s:sub(1, #s)

>>> In a language that used the half-open interval convention we would end up with:

    s:sub(0, #s)

>> You would end up with:

     s:sub(0, #s - 1)

> That would be strange, in Ruby

    s[0, s.length]

Your argument against 0-index is just plain wrong. No one creates such API. It would be to awkward - either #s should be `length + 1` or `sub` should expect `length + 1`.

----

>>>> Once you get used to it, ... you don't need math when grabbing a range.

I assure you once you get used to 0-indexing there is no need for math when grabbing a range

    s[0..s.length] # that is identity through range in ruby 

----

>>>>> 1-index kept throwing me off though

>>>> it does help prevent a whole bunch of off by one errors

You claim superiority, it is not. I can't remember such errors in my life. It may be easier to describe to children but I doubt it. My first encounter with 0-indexing was with ruler - "why it starts with 0?" - pre-school. I can claim 0-index is natural. I would not.

There is no better model just "happy accidents".

unless the fantasy-lua went all the way and `#` returned the offset of the last element, that is, the length minus one

Yes. There are pros-and-cons of 1-based indexing when considered in isolation. But for Lua, a language that’s commonly used tightly-coupled to C, 1-based indexing is extremely awkward.

It’s unfortunate that Lua makes some strange decisions, but the powerful functionality totally outweighs the weirdness (metatables are especially cool). I really like Lua, especially for game programming with LÖVE.

"strange" in the sense of different from other languages in 2020, yes, but not strange from the perspective of its developers.

Lua is a language for both hardcore C programmers and complete n00bs wanting to configure their C programs. In that context, position-based indexing makes much more sense, as it's how most non-programmers think.

I find it strange that you choose to use terminology that does not uniquely identify what you are talking about when the rest of the thread uses terminology that does uniquely identify what they are talking about

How about this: The empty string and 0 are truthy. Why?

0? Because Lua isn't C. It makes sense for C to treat 0 as falsey, because (void*)0 is Cs way of expressing a nil-value, as well as not having a dedicated boolean value to keep the language simpler.

Lua, both has a dedicated nil value and a boolean type, so there's no reason whatsoever to treat zero as falsey, other than the C cargocult.

As for empty strings, I really don't see the rationale behind it. An empty string is not nothing. At the very least, it still holds the length-data of 0, so it's conceptually more than just nil and should thus still be truthy.

Maybe because all variables are `nil` by default, and checking on undeclared variables does not raise an error. So `if foo then ... end` is often used as an existence check, where `foo = 0` should be truthy.

If you make the empty string falsy, surely you need to make all empty collections falsy?

Python does this, which leads to people checking whether a list is empty using `if l` rather than `if len(l) > 0`. I‘d rather they stuck with “explicit is better than implicit”.

This is probably a good thing, if you don't want to have tickets filed about whether midnight (time of day) is truthy, whether Jan 1, 1970 is truthy, why some type of empty collection is truthy but others are not, etc.

> This is probably a good thing, if you don't want to have tickets filed about whether midnight (time of day) is truthy

Agreed. Here is an example of exactly that in Python:

https://bugs.python.org/issue13936

I think 0-index causes a lot of new programmers (and non-programmers) confusion because they aren't used to treating 0 as a counting instance. For example, A.D. 2020 suggests that (allowing for the various changes and debates) Jesus was born 2020 years ago, instead of counting the first year which would make (2021-1 day) years ago. I see this every year around New Year, headlines saying "Actually, it will be [year + 1]"