Hacker News Reader

Comment by chii | Hacker News Reader

> basically no confusing elements.

the one confusing element - one-based indexing of arrays! that is something i found hard to adjust, as it makes off-by-one errors more prominent...

but otherwise it's a nice language.

View on HN

I agree, that's the one unfortunate flaw of Lua I'd go back in time and change if I were Hitler With a Time Machine, but I've used Lua and other 1-based languages like ScriptX, and you totally get used to it, and finally realize that 0-based languages have their own confusing quirks and inconveniences that you got used to when you learned them, and you just don't think about them any more once you've internalized them, just like 1-based languages. It's just a matter of moving the confusing quirks and complexity around, not that 0-based languages are less confusing, complex, or quirky than 1-based languages, or the other way around.

But that said, I'd prefer that Lua had 0-based indexes, simply because that's what most other languages have, not because it's superior.

> It's just a matter of moving the confusing quirks and complexity around

unless you can exclusively program in 1 language only, these confusions would be the cause of various bugs, or at least, increase the cognitive load. Programming is already hard enough, without artificially increasing the cognitive load!

I certainly prefer 0-indexed these days, but starting on 1-indexed languages (A variety of BASIC’s) I found 0-indexing just as weird.

If you work with pure Lua that’s a non issue. The ipairs function abstracts that away, and for numerical loops are written different than in C, with a start value (included), an end value (included) and a step (optional), and no exit condition. You can’t put i<len there as a result like you would do in C.

Agreed that interaction with C or other 0-based languages or systems (eg screen coords) makes things more difficult.

iirc, one other confusing element is that tables (hash tables? I don't remember what they're called) return null when a lookup is done for a nonexistent key.

This is not necessarily a bad choice. Exceptions and such can be a real pain. However, accidentally getting a null value because you didn't check and then have it propagate much further in your program is extremely difficult to debug. Instead of blowing up at the site of the bad lookup, you only see the distant effects of it (e.g. put the null value into another table, which gets put in another table, and then is attempted to be called as a function, etc).

It even does this for globals (which are just another table), so there’s never an “undefined variable” error (even though there really is).

It’s pretty unfortunate. You can mitigate it using meta tables though.

Storing a null value is a legitimate operation. How do you distinguish "never stored a value under key K", and "stored null under key K"?

I'm pretty sure you're agreeing with them. Current Lua does this, which is wonky:

    > t = {}
    > t['a'] = nil
    > t['a']
    nil
    > t['b']
    nil

Give Teal [1] a look. It’s basically typescript for Lua

https://github.com/teal-language/tl

Same here. It's not a big deal once you get used to it but after years of always having indexes start at 0 it just seems... off.

If you learned arrays in C where indexing is the same as pointer arithemetic then zero-based arrays seem natural. If you are coming from the real-world concept of "a list of things" then the "zero-th item" in the list seems odd; one-based indexing feels natural.

That's not really confusing though, just takes a bit of unlearning the muscle memory of 0-based indexing.

Reply on news.ycombinator.com