1-based indexing is great. It's just _different_ - from C, where the array index is just sugar for pointer arithmetic, and from other languages which borrowed the practice without reasoning.
> we had better regard —after all those centuries!— zero as a most natural number
Of course, a counter argument is that we've already made the mistake of indexing with 1 in natural language (first, second, ...). That decision is not free of annoyances, though: the 19th century are year numbers 18xx, floors below the first have a varying names when they could have been negative numbers, etc.
That EWD is one if my pet peeves. Dijkstra makes an unfair comparison because he lists plenty of examples where 0-based indexing is more convenient but ignores the equally numerous situations where 1-based is more convenient. For example, iterating backwards over an array is much better in an 1-based world.
To be honest, I actually agree that Dijkstra's argument seem a bit one sided. It's also interesting to see the argument in your linked article that offset and index doesn't have to be the same.
If I get the root of the argument in the linked article, it is that zero-based indexing is more of a optimization than anything, but I would disagree; there are reasons beyond that (see the examples in my previous comment).
Also, here's an example of an 1-index based system that has caused me some headaches: In music theory, the first note of the scale is called the "first", etc. It also talks about e.g. "stacking thirds", which means take the third of the scale, than take the third from there. However, the offsets are two. (first=offset 0, second=offset 1, third=offset 2). Which is hard to work with in my opinion.
You have an interesting argument about iterating backwards, although I would say; if we need a tie-breaker between the two, iterating forward should have more weight than backwards.
I appreciate your comment, and while trying as best I can to be convinced of the "other side", I still land on 0-indexing. The only argument I buy, is that it matches our natural language starting at 1. Which, of course, is a strong argument.
The reasoning is to be consistent with C and it's more than enough reasoning for me. I don't know if 1-based indexing is fundamentally better. However, I know the probability that I will need to use other languages in the future is 100%, and they'll use 0-based index.
Due to the embedded nature of Lua, it’s often impossible or difficult to use libraries. And I don’t want to reimplement basic functionality every time I start a new project.
That seems like a contextual problem, not a Lua problem.
If you're in Love and/or control the environment you're free to bring in whatever libraries you want. Or to build your wrapper to support multiple files from the user.
Like you could suffer from a bad embedded scripting setup with any language. Granted if it was embedded Python or Javascript you would get a bit more for builtin if they embed a full implementation. But also embedding Lua with support for user supplied libraries is less effort than embedding a whole Python/JS runtime
> Due to the embedded nature of Lua, it’s often impossible or difficult to use libraries.
Last time I used LÖVE that wasn't the case, nor does it seem to be the case today, you can require libraries or even use LuaRocks if that is what you prefer, and everything just works.
well, it is true that the second one is more concise.
The only difference is that one of the language is embedded and barely takes any place. it's just a few C files :-D It offers just enough functionality while not making it overly complicated to make basic things.
The other one is way way bigger. and even Array.filter didn't exist from the start
Small stdlib, “implement it yourself” philosophy to even things like classes, diverging language versions and fragmentation (a lot of people don’t like any of the post 5.1 changes), bad tooling and editor support, dynamic duck typed language with no type hints
If it were about making a choice of which web framework to use on the server, obviously you wouldn't want to use Lua.
But if it is about using it as an embedded language. you want just enough language to get you started and be able to tweak controls. so that the embedded language itself doesn't take up unnecessary space, on its own.
It's a design choice to have a language as small as possible while still offering cool tools.
I don't necessarily hate Lua, but I prefer C and Raylib for game dev. Lua is garbage collected, dynamically typed, strays far from standard syntax patterns, and has less existing tooling than C.
I see why people might hate Lua. Especially for game dev!
A JIT is a double edged sword, it _can_ make your code faster, i remember in the early days of smartphone gaming, developers often had to manually "warm up" the JIT to prevent stutters during gameplay
Similar story with the GC, it's nice to have, until it causes you problems (wich it will), so you end up having to avoid using it and instead rely on manual techniques
JIT and GC aren't the panacea people make them out to be
True using a JIT without understanding it is not a panacea. Same as a GC. Same as malloc and free (you're often much better off with arena allocators).
Most JITs let you tune when and how they inline. It's also worth knowing how they works and what they can/can't inline.
You linked to monojit. Luajit is a whole other beast. I'd argue it's superior to anything in JS/JAVA/C# land (and I say that as someone with a reasonable understanding of the JVMs C2 JIT).
As an aside with low latency GCs like the JVM's ZGC trading manual memory management for no memory related security vulnerabilities is pretty appealing.
For all the reasons, but the 1-based index alone makes me uncomfortable.
1-based indexing is great. It's just _different_ - from C, where the array index is just sugar for pointer arithmetic, and from other languages which borrowed the practice without reasoning.
There are arguments for why 0-based indexing is _better_, unrelated to pointer arithmetic. https://www.cs.utexas.edu/~EWD/transcriptions/EWD08xx/EWD831...
> we had better regard —after all those centuries!— zero as a most natural number
Of course, a counter argument is that we've already made the mistake of indexing with 1 in natural language (first, second, ...). That decision is not free of annoyances, though: the 19th century are year numbers 18xx, floors below the first have a varying names when they could have been negative numbers, etc.
That EWD is one if my pet peeves. Dijkstra makes an unfair comparison because he lists plenty of examples where 0-based indexing is more convenient but ignores the equally numerous situations where 1-based is more convenient. For example, iterating backwards over an array is much better in an 1-based world.
I like the argument that 1-based is better for indexing and 0-based is better for offsets: https://hisham.hm/2021/01/18/again-on-0-based-vs-1-based-ind...
To be honest, I actually agree that Dijkstra's argument seem a bit one sided. It's also interesting to see the argument in your linked article that offset and index doesn't have to be the same.
If I get the root of the argument in the linked article, it is that zero-based indexing is more of a optimization than anything, but I would disagree; there are reasons beyond that (see the examples in my previous comment).
Also, here's an example of an 1-index based system that has caused me some headaches: In music theory, the first note of the scale is called the "first", etc. It also talks about e.g. "stacking thirds", which means take the third of the scale, than take the third from there. However, the offsets are two. (first=offset 0, second=offset 1, third=offset 2). Which is hard to work with in my opinion.
You have an interesting argument about iterating backwards, although I would say; if we need a tie-breaker between the two, iterating forward should have more weight than backwards.
I appreciate your comment, and while trying as best I can to be convinced of the "other side", I still land on 0-indexing. The only argument I buy, is that it matches our natural language starting at 1. Which, of course, is a strong argument.
The reasoning is to be consistent with C and it's more than enough reasoning for me. I don't know if 1-based indexing is fundamentally better. However, I know the probability that I will need to use other languages in the future is 100%, and they'll use 0-based index.
It's like right-click-to-select.
In many aspects, Lua is more verbose and awkward than other similar languages. Compare
withIt's more minimalistic, that's true. But there's nothing stopping you writing or downloading an array library so you can do this:
Or even setting a metatable so you can do:Due to the embedded nature of Lua, it’s often impossible or difficult to use libraries. And I don’t want to reimplement basic functionality every time I start a new project.
That seems like a contextual problem, not a Lua problem.
If you're in Love and/or control the environment you're free to bring in whatever libraries you want. Or to build your wrapper to support multiple files from the user.
Like you could suffer from a bad embedded scripting setup with any language. Granted if it was embedded Python or Javascript you would get a bit more for builtin if they embed a full implementation. But also embedding Lua with support for user supplied libraries is less effort than embedding a whole Python/JS runtime
> Due to the embedded nature of Lua, it’s often impossible or difficult to use libraries.
Last time I used LÖVE that wasn't the case, nor does it seem to be the case today, you can require libraries or even use LuaRocks if that is what you prefer, and everything just works.
well, it is true that the second one is more concise.
The only difference is that one of the language is embedded and barely takes any place. it's just a few C files :-D It offers just enough functionality while not making it overly complicated to make basic things.
The other one is way way bigger. and even Array.filter didn't exist from the start
Alright, here is Janet, which is designed to be embeddable just like Lua:
Though JavaScript has QuickJS, which is also lightweight.Small stdlib, “implement it yourself” philosophy to even things like classes, diverging language versions and fragmentation (a lot of people don’t like any of the post 5.1 changes), bad tooling and editor support, dynamic duck typed language with no type hints
If it were about making a choice of which web framework to use on the server, obviously you wouldn't want to use Lua.
But if it is about using it as an embedded language. you want just enough language to get you started and be able to tweak controls. so that the embedded language itself doesn't take up unnecessary space, on its own.
It's a design choice to have a language as small as possible while still offering cool tools.
> If it were about making a choice of which web framework to use on the server, obviously you wouldn't want to use Lua.
Wait just a minute, there exist many web frameworks in lua, and programmers who enjoy lua might want to use them.
[dead]
I don't necessarily hate Lua, but I prefer C and Raylib for game dev. Lua is garbage collected, dynamically typed, strays far from standard syntax patterns, and has less existing tooling than C.
I see why people might hate Lua. Especially for game dev!
Luajit is often faster than C. The qualities you described above actually make it great for game dev.
A JIT is a double edged sword, it _can_ make your code faster, i remember in the early days of smartphone gaming, developers often had to manually "warm up" the JIT to prevent stutters during gameplay
It still is an issue nowadays https://discussions.unity.com/t/app-needs-warmup-first-slow-...
Similar story with the GC, it's nice to have, until it causes you problems (wich it will), so you end up having to avoid using it and instead rely on manual techniques
JIT and GC aren't the panacea people make them out to be
True using a JIT without understanding it is not a panacea. Same as a GC. Same as malloc and free (you're often much better off with arena allocators).
Most JITs let you tune when and how they inline. It's also worth knowing how they works and what they can/can't inline.
You linked to monojit. Luajit is a whole other beast. I'd argue it's superior to anything in JS/JAVA/C# land (and I say that as someone with a reasonable understanding of the JVMs C2 JIT).
As an aside with low latency GCs like the JVM's ZGC trading manual memory management for no memory related security vulnerabilities is pretty appealing.
Like everything in programming it's a trade off.
Lua is extremely popular for game dev though?