Is there any reason to not just switch to 1-based indexing if we could? Seems like 0-based indexing really exacerbates off-by-one errors without much benefit
That said, I'm not sure how 1-based indexing will solve off-by-1 errors. They naturally come from the fencepost problem, i.e. the fact that sometimes we use indexes to indicate elements and sometimes to indicate boundaries between them. Mixing between them in our reasoning ultimately results in off-by-1 issues.
This is an article that (among other things) talks about off-by-one errors being caused by mixing up index and count (and having to remember to subtract 1 when converting between the two). That's what it has to with it.
If you always use half-open intervals, you never have to subtract 1 from anything.
With half-open intervals, the count of elements is the difference between the interval bounds, adjacent intervals share 1 bound and merging 2 adjacent intervals preserves the extreme bounds.
Any programming problem is simplified when 0-based indexing together with half-open intervals are always used, without exceptions.
The fact that most programmers have been taught when young to use 1-based ordinal numbers and closed intervals is a mental handicap, but normally it is easy to get rid of this, like also getting rid of the mental handicap of having learned to use decimal numbers, when there is no reason to ever use them instead of binary numbers.
When accessing individual elements, 0-based and 1-based indexing are basically equally usable (up to personal preference).
But this changes for other operations! For example, consider how to specify the index of where to insert in a string. With 0-based indexing, appending is str.insert(str.length(), ...). With 1-based indexing, appending is str.insert(str.length() + 1, ...).
Similarly, when it comes to substr()-like operations, 0-based indexing with ranges specified by inclusive start and exclusive end works very nicely, without needing any +1/-1 adjustments. Languages with 1-based indexing tend to use inclusive-end for substr()-like operations instead, but that means empty substrings now are odd special cases.
When writing something like a text editor where such operations happen frequently, it's the 1-based indexing that ends up with many more +1/-1 in the codebase than an editor written with 0-based indexing.
My opinion is that 1-based indexing really exacerbates off-by-one errors, besides requiring a more complex implementation in compilers, which is more bug-prone (with 1-based addressing, the compilers must create and use, in a manner transparent for the programmer, pointers that do not point to the intended object but towards an invalid location before the object, which must never be accessed through the pointer; this is why using 1-based addressing was easier in languages without pointers, like the original FORTRAN, but it would have been more difficult in languages that allow pointers, like C, the difficulty being in avoiding to expose the internal representation of pointers to the programmer).
Off-by-one errors are caused by mixing conventions for expressing indices and ranges.
If you always use a consistent convention, e.g. 0-based indexing together with half-open intervals, where the count of elements equals the difference between the interval bounds, there are no chances for ever making off-by-one errors.
I would bet that in the opposite circumstance you'd say the same thing:
"Is there any reason to not just switch to 0-based indexing if we could? Seems like 1-based indexing really exacerbates off-by-one errors without much benefit"
The problem is that humans make off-by-one errors and not that we're using the wrong indexing system.
No indexing system is perfect, but one can be better than another. Being able to do array[array.length()] to get the last item is more concise and less error prone than having to add -1 every time.
Programming languages are filled with tiny design choices that don’t completely prevent mistakes (that would be impossible) but do make them less likely.
Having to use something like array[length] to get the last element demonstrates a defect of that programming language.
There are better programming languages, where you do not need to do what you say.
Some languages, like Ada, have special array attributes for accessing the first and the last elements.
Other languages, like Icon, allow the use of both non-negative indices and of negative indices, where non-negative indices access the array from its first element towards its last element, while negative indices access the array from its last element towards its first element.
I consider that your solution, i.e. using array[length] instead of array[length-1], is much worse. While it scores a point for simplifying this particular expression, it loses points by making other expressions more complex.
There are a lot of better programming languages than the few that due to historical accidents happen to be popular today.
It is sad that the designers of most of the languages that attempt today to replace C and C++ have not done due diligence by studying the history of programming languages before designing a new programming language. Had they done that, they could have avoided repeating the same mistakes of the languages with which they want to compete.
array[array.length()] is nonsense if the array is empty.
You should prefer a language, like Rust, in which [T]::last is Option<&T> -- that is, we can ask for a reference to the last item, but there might not be one and so we're encouraged to do something about that.
IMNSHO The pit of success you're looking for is best dug with such features and not via fiddling with the index scheme.
Fundamentally, CPUs use 0-based addresses. That's unavoidable.
We can't choose to switch to 1-based indexing - either we use 0-based everywhere, or a mixture of 0-based and 1-based. Given the prevalence of off-by-one errors, I think the most important thing is to be consistent.
Because it is not how computers work. It doesn't matter much for high level languages like LUA, you rarely manipulate raw bytes and pointers, but in system programming languages like Zig, it matters.
To use the terminology from the article, with 0-based indexing, offset = index * node_size. If it was 1-based, you would have offset = (index - 1) * node_size + 1.
And it became a convention even for high level languages, because no matter what you prefer, inconsistency is even worse. An interesting case is Perl, which, in classic Perl fashion, lets you choose by setting the $[ variable. Most people, even Perl programmers consider it a terrible feature and 0-based indexing is used by default.
> Is there any reason to not just switch to 1-based indexing if we could? Seems like 0-based indexing really exacerbates off-by-one errors without much benefit
You'd just get a different set of off-by-one errors with 1-based indexing.
1-based indexing doesn’t work well as soon as you have a start offset within a sequence, from which you want to index. Then the first element is startIndex + 0, not startIndex + 1. 0-based indexing generalizes better in that way.
I think that many obo errors are caused by common situations where people can mistakenly mix up index and count. You could eliminate a (small) set of those situations with 1-based indexing: accessing items from the ends of arrays/lists.
The idea of languages "stealing" ideas from each other is not something anyone building a language cares about. I'll just charitably assume you've completly misinterpreted something he said.
I've seen a hundred ai-generated things, and they are rarely interesting.
Not because the tools are insufficient, it's just that the kind of person that can't even stomach the charmed life of being a programmer will rarely be able to stomach the dull and hard work of actually being creative.
Why should someone be interested in you creations? In what part of your new frictionless life would you've picked up something that sets you apart from a million other vibe-coders?
> stomach the dull and hard work of actually being creative
This strikes me as the opposite of what I experience when I say I'm "feeling creative", then everything comes easy. At least in the context of programming, making music, doing 3D animation and some other topics. If it's "dull and hard work" it's because I'm not feeling "creative" at all, when "creative mode" is on in my brain, there is nothing that feels neither dull nor hard. Maybe it works differently for others.
I've loved using Godot more, and it's been very informative as the first big OSS project where I'm closely following the development / proposals / devchat. I don't agree on many of the points by people downthread: I use C# almost exclusively and while it's been awkward (and clearly not a "priority") it's pretty seamless to use once you set up some stuff (though it certainly helps if you keep much of your logic in C# and mostly use Godot as a frontend, crossing the boundary is kinda awkward and slow).
Having said that, I do agree that Godot has a bit of complicated identity: it is at once geared towards being a good first programming experience, and a general purpose replacement for stuff like Unity.
I'd prefer a focus on the second part, there's a huge industry of game-devs right now, and providing them with the stability of a solid, free, transparent engine would be a great service.
I'm in the same position, I use C# both because that sort of syntax is more familiar to me, but also because it just seems better as a language (in terms of both code structure and performance).
There's a lot of downplaying of the advantages of C# in the Godot community, seemingly moreso by people who are amateur game devs/programmers, who perhaps just don't need the advantages for their particular kind of game.
I am a C# dev by day and love working with it. I miss interfaces, Linq, and the nicer pattern matching features of C# when using GDScript, but overall GDScript is quite adequate for what it needs to do and the game dev loop feels faster when using it. They can interop as well without too much friction, so if you have the .NET version of Godot, it can have some code in C# where (if?) you need it and other code in GDScript when you don’t.
I am responding to the fact US TikTok does not show videos of an armored vehicle driving through a crowd of protesters standing in front of it like the lone man in Tiananmen Square. They are being removed.
This ability to control what information TikTok users are presented with is the reason TikTok was originally banned in the United States.
I am being objective discussion how TikTok is being used as a propaganda tool whether or not I personally agree with China influencing people in South America or whether or not what the United States government is doing to protestors is good or bad. I'm not putting a value on it. I'm pointing out that when I'm in South America and someone links a video in a text message and I start to doom scroll after a while I will start to be introduced to videos of the Unites States government committing violence against Spanish speaking people.
> might be immensely popular in South America
Objectively the current United States regime was hugely popular in Spanish speaking countries like it was in Spanish speaking Florida. Up until a couple months ago, people would tell me how much they support and admire the current regime in the United States. That has changed recently which likely has to do with the content they receive via TikTok which is controlled by the Chinese government which is why it was banned in the United States. After being sold, it is not surprising that the United States is using it the way they accused the Chinese of using it.
When you look at something like Pietà by Michelangelo or Lolita by Vladimir Nabokov, you realise that some humans are given abilities that far exceed your own and that you will never reach their level.
When this happens, you need to stop and appreciate the sheer genius of the creator.
I’ve been working on a fontdrawing app that only uses the keyboard (inspired by vim) for a couple of months. Finally got export to ttf working this weekend and got to see a bad looking j I drew in Figma
reply