(The above is a quote from another topic, but I think it’s more appropriate to further discuss it here)
Even in Snap! for some tasks, e.g. in many 2D operations, 0-based indexing is more suitable than 1-based. The example below is from code I wrote for Advent of Code 2023, day 21; it calculates the index of a node within a list representing a 2D-map from the puzzle input (my implementation of Dijkstra’s shortest path algorithm expects a network to be represented by links referring to consecutive node numbers from 1). I’m hinting at 
, of course.
Also, when working with Snap!’s primitive graphics blocks, you will need to address pixel maps in a similar way,
And what about 
? Suppose you want to convert a very long (perhaps virtual) list to a much shorter bucket list, with a limited number of buckets. Then you’d have to make calculations like:
I’m not saying it’s all such a big deal, and I recognize the advantages of 1-based indexing, but what I am saying is, 0-based indexing is not “bizarre”.
Update
As an alternative for developing an 1-based Snap! fork, I (seriously 
) propose the following functions as primitives:
, meaning +1, 
meaning -1,
and a variety of MOD:
