> 1. Naturally, the first element in a list cardinally corresponds to 1. Contrarily, even official documentation of JavaScript has explicit disclaimers that the

> 1. Naturally, the first element in a list cardinally corresponds to 1. Contrarily, even official documentation of JavaScript has explicit disclaimers that the "first element of an array is actually at index 0" - this is easily forgotten, especially by novices, and can lead to errors. 'Cardinally' is wrong; it refers to cardinality, i.e. measuring the size, not indexing. It's just a historical accident that indexing traditionally started with one, and most languages lack a word for an ordinal number corresponding to zero. That's mostly because for a long time zero hasn't even been recognised as a number at all. But the Ancient Greeks didn't recognise 1 as a number either. We've grown past that. > 2. [...] This matters because code deals with integer intervals, because all elements have a fixed size - you can not access a fractional part of an element. Integer intervals are closed intervals, thus conclusively proving this importance. Half-open intervals preserve the property that [a,b) ∪ [b,c) = [a,c) whether the domain is discrete or not. Half-open intervals generalise well both to empty ranges and infinite ones. In fact, in set theory ordinal numbers can be said to be defined as half-open intervals starting with zero (according to the most popular modern definition): an ordinal is simply the set of all ordinals that precede it. The 'fractional part of an element' is nonsense. > 3. Mathematically, matrix notation also starts with 1. This is just a historical accident as well. > 4. The last element in a list cardinally corresponds to the length of the list, thus allowing easy access with items.length rather than having frustrating (items.length - 1) arithmetic everywhere in your code. That is somewhat obtuse, but I don't believe it outweighs other concerns. And again, not 'cardinally'. > 5. Negative indices are symmetric with positive indices. Such that -1 and 1 respectively refer to the last and first element, and in the case where there is only one item in the list, it matches the same element. This convenience allows for simple left and right access that offset notation does not provide. Zero-based indexing together with negative indexing lets you effortlessly treat any list as a circular list. Which is related to the reason why people bring up modulo all the time, by the way. Tangentially, Lua uses this very convention (1-based indexing, closed ranges and negative indexing) in its string functions. It annoys me every time I write something parser-like by hand. > 6. Non existence of an element can be represented by 0, which would conveniently code elegantly as if( !items.indexOf('z') ) return; Rather, one must decide upon whether if( items.indexOf('z') == -1 ) return; is philosophically more meaningful than if( items.indexOf('z') < 0 ) return; with offset notation despite ignoring the asymmetry of the equation. The first is obviously more sensible. Failure to find an element might just as well be represented by a null; that the value chosen to represent it is an integer smaller than any valid index is mostly an accident. In a better-designed programming language, a function equivalent to indexOf would have a return type of an option type of a valid index. The language would also have pattern-matching constructs handling it with a syntax just as snappy as a boolean negation is in JavaScript. (Why? For one, because it generalises well to maps of arbitrary type.) This remark proves little apart from pointing out the shortcomings of JavaScript's type system.