Lambda the Ultimate

You might want to mention this is from 1982 and by E.W. Dijkstra
Indeed - fixed.

From an earlier comment by dough:

1 ≤ i ≤ N is nicest then?

Yes it is. His argument here is a straw man. There are several ways to denote the ranges given a particular indexing strategy. He chose to use the method that made his preference more aesthetic. In fact the only reason I can think of that we use a "<" instead of a "≤" when comparing i to n, is because we choose to start indexing at 0, not the other way around.

Dijkstra's resulting "moral of the story" is also suspect. His conclusions are correct (from a set theoretical point of view) zero, as the first natural number (Peano axioms) could indeed be considered the most natural number, but he's failed to convince me that natural numbers have anything to do with indexing. Was the point here an attempt to convince the audience that zero is more natural, or that his premise must be correct because his conclusion is correct?

What does an index do? It tells the position of an element in an ordered collection. What kind of numbers do we use for this purpose? Is the answer natural numbers? No. This argument is spurious. Natural numbers are for counting. Ordinal numbers are for giving the position in an ordered sequence: 1^st, 2^nd, 3^rd, 4^th, ...

For specifying intervals, there is a reason for using ≤/≤ in addition to ≤/

It is true that certain enumerable quantities do not have an upper bound (such as the set 1/n for all natural numbers n≥1). However, any finite ordered sequence has last element. Since the argument here is in regards to indexing of sequences, we must keep this in mind when discussing the validity of ≤/≤ v.s. ≤/< for ranges on indexes. If the range of indexes is given as 0≤n<n then this is equivalent to the more balanced (because it uses inequalities on both sides) 0≤n≤n-1.

More to the point, although the use of indexing for the purpose of iterating over the entire sequence is a moot point, (as others have already mentioned, there are much better methods for enumerating over an entire sequence), there is still a need for having an indexing strategy on sequences, namely denoting subsequences via ranges. Thus we are left with two interpretations: do I want do denote my subsequence based on position in the array (the 4^th to the 9^th) or on distance from the 1^st element?

The (big) question is, how do you specify an empty sequence?

any finite ordered sequence has last element

Do you still think so?

Point taken. I should have said: Any non-empty finite sequence has a last element.

Do you really want to introduce a special "empty sequence" case into every piece of code that deals with a finite sequence of unknown length?

You mean like with the empty list?

I'm glad you asked that, as I should have remembered it in my original list. An empty sequence can be specified as a <= i < a for any value of a. Using the both-ends-included convention (<= for both relations) means that one has to write something like a <= i <= a - 1, which strikes some eyes (mine included) as unobvious and jarring.

a <= i < a means that you have not one representation of the empty set but as many notation as there is a value 'a'.

a <= i <= a - 1 is not good either.

For me a good reason to have array starting at 0 is that it's quite natural when you want to put into array the result of "How many values occurred i times?".

It usually leads to simpler formulas than indexing from 1, with less +1/−1 adjustments, especially when working on intervals and when scaling them to other units.

Consider the translation between two-dimensional indexing and one-dimensional linearization of the elements: with 0-based indices, it's i·n+j; with 1-based indices, it's (i−1)·n+j.

If people had been numbering years and centuries starting from 0, then computing the century of the year would be simpler: year 1977 would be in 19th century, 2000 would be in 20th one. The present convention is shifted by 99 years.

It usually leads to simpler formulas than indexing from 1, with less +1/−1 adjustments, especially when working on intervals and when scaling them to other units.

I agree with this up to a point. I'm not exactly sure what you mean by ranges, but it certainly is the case for things like finding midpoints and scaling (as you mentioned). However, should modern languages force the user to deal with such low level details as linearizing a two dimensional array?

Perhaps I was a little too strong in my "anti zero based indexing" rant? Initially, when I started writing the above post, I admitted that there are cases where zero based indexing makes more sense, but my main gripe was with Dijkstra's faulty arguments (which I found somewhat surprising, because I usually find his "rants" amusing and enjoyable), so I ended up removing that confession.

...year 1977 would be in 19th century, 2000 would be in 20th one...

A minor nitpick, and a great source of confusion in the great 0-based/1-based indexing argument:

I think you mean the year 1977 would be in the century 19, as it would still be the 20^th century, because 20^th is an ordinal, and ordinals always start at the 1^st. (Currently we don't number our centuries, we reference them by ordinals,). This is my main gripe with zero-based indexing is that it trades one type of complexity for another: what does a[1] mean? Does it mean the 1^st or the 2^nd (both positional questions)? When we are dealing with an ordered sequence, getting at the n^th element can become confusing.

"What does an index do? It tells the position of an element in an ordered collection."
You can maybe look at it differently and much simpler as a partial function over N. Then it is probably nicer to start at n=0.

Are you suggesting C is inflexible in this regard. Remember the evil of pointer arithmetic?

int a[5];
int *offset_a = a - 1;
offset_a[1] = 1;
offset_a[5] = 5;
assert(a[0] == 1);

The pointer subtraction in the second line of your example is undefined. See the C FAQ.

Remember, in the real world, if an End User has a nice shiny nickle, he or she has one nickle, nickle one, not nickle zero!

That's a different question: "how many nickels do I have". This whole issue depends on first deciding what question you're most interested in. Dijkstra proposes asking the question "How many elements appear before the one you want to identify?" BTW, I dispute the claim that End Users possess intuition.

BTW, I dispute the claim that End Users possess intuition.

Okay, I'll bite (although I will assume that this aside may have been at least partially tongue in cheek) because as the head of The Institute for End User Computing, it is my job to make the case for 'intelligent End User life out there'.

However, I'll agree with you in the context of our discussion, in so far as End Users probably don't think about using offsets and iterating over subsequences by advancing one or more pointers as a natural way to solve any sort of problem.

So even the idea of framing Dijkstra's question in the first place would most likely be outside the scope of their intuition, which is a quite different thing than saying that they don't posses intution about any sort of computation.

Indeed, End Users would most likely assume they could just name a sequence and do something to all of the elements in that range, because we humans natively perform that sort of process in closed form.

But if asked:

If a number in square brackets following a name represents some sort of offset or component element descriptor that stands for one of the items in a list identified by that name, would "my_list[2]" mean the second or third item in "my_list"?

I'd be willing to bet that a statistically significant number of End Users would intuitively pick the former over the latter. This should be empirically testable and repeatable which would validate my hypothesis that End Users do have intuition with respect to such notation. QED

Okay, I'll bite (although I will assume that this aside may have been at least partially tongue in cheek)

You assume correctly. However, dragging intuition into a discussion is a guarantee of fuzzy thinking to follow. At the very least, you need to define what you mean by the word. For example, a dictionary definition doesn't seem to apply in this case: if "direct perception of truth, fact, etc., independent of any reasoning process" or "pure, untaught, non-inferential knowledge" is at work here, how do we explain the fact that "third" in one context can mean "fourth" in another, as I've pointed out in another comment? There does not seem to be an argument for either meaning being inherently more intuitive.

What I suspect is actually meant by "intuition" here is exactly what Jef Raskin proposed, which is that Intuitive equals familiar. But "familiar" is dependent on what the user has already been exposed to, and varies according to a wide range of factors. Certainly, assumed familiarity can be a reasonable basis for a design, but it should not be confused with some sort of ability to directly perceive truth. Only Dijkstra possessed that.

My preference for zero based indexing is related to Dijkstra's question rephrased.

Anton van Straaten: Dijkstra proposes asking the question "How many elements appear before the one you want to identify?"

I prefer the question: "How many members must you skip before the desired spot?" And sometimes I use the name "skip" instead of position or index to emphasize the issue (especially when a data structure has a btree shape such that indexing is skipping-centric). It unifies terminology for current members and future additions to the end. If eos (end of sequence) is the count of members, it's also the position at which new members append when skipping all current members. Since eos and size() are synonymous, this eliminates opportunities for still more off-by-one errors.

My view is spatial (relative positions of items occupying space) and constructive, instead of verbal and declarative. I prefer semantics most cleanly expressing accumulation and editing of existing sequences over time -- it seems less messy with zero based positions. Editing is all about calculating where to put things, which involves knowing how much to skip before making cuts. Zero-based distance is clear.

Iterating over sequence members seems a minor use case. Instead, if you want to find what causes awkwardness and what doesn't, try expressing insertions and deletions in a sequence, with use cases including empty sequences and appends. Zero based indexing seems to have fewer edge conditions.

Dijkstra proposes asking the question "How many elements appear before the one you want to identify?"

I always thought that question was only asked to justify his position. Why would the person be asking about the element before the one they wanted? Consider...

Dijkstra: Take the door after the third door on the left.
Everyone else: Take the fourth door on the left.

Jonathan Allen: I always thought that question was only asked to justify his position.

I was never aware of Dijkstra's paper or his question before I read this thread, and yet his question was like one I asked myself a few years ago, when I wasn't trying to compare zero and one-based indexing. I was trying to summarize arithmetic on (e.g. byte) sequences with the fewest exceptions in words.

But Dijkstra's question is awkward because it seems to care about elements before a member you want. Instead, it's more clear to ask the question in terms of how a sequence finds a position for a member, whether the member has been added yet or not. (Yeah, you might consider this a systems programmer view, but it doesn't invalidate the idea that multiple simultaneoous viewpoints can be true.)

Look at it this way. The index has meaning only in the context of a relationship between sequence and member. The sequence seems primary here, since it's only because the sequence is ordered that indexes are ordered too. So I think it's natural to give priority to the sequence's coordinate system, which has an origin a zero when a sequence is empty. If you wanted to use the same notation before and after you had added the first member, you can make eos a legal index for writing: s[0] = x.

(Note to functional programming folks: assignment needn't mutate state in expressions like this; it can instead return a new value where the change is visible, without modifying old state. And you can make it cheap using copy-on-write with immutable state sharing.)

The problem in terminology resembles that in local and global coordinate systems, say when trying to refer to something inside a sub-view when each view has it's own view transform. (Think about mapping mouse clicks global-to-localinto nested views from systems events, or the reverse local-to-global when expressing view coordinates in a message that must make sense to entities outside the view.)

Both local and global coordinate systems are "true." Arguing that one is nonsense because the other is more understandable is silly. But the local coordinate system of the sequence is "object oriented" and therefore unpalatable to new users, because they don't have as much practice seeing from other viewpoints than their own. But the object's perspective is going to generate a more consistent description of a series of things that happens to the object.

The person isn't asking about the element before the one they want, they're asking how many elements to skip, as Rys pointed out.

Consider...

Dijkstra: Take the door after the third door on the left.
Everyone else: Take the fourth door on the left.

This example depends on biased language. In England, if you were talking about floors in a building, the floor that (U.S.) Americans would identify as "fourth" is called "third". So the above example becomes:

England: Take the lift to the third floor.
U.S.: Take the elevator to the fourth floor.

Somehow, those wacky Brits actually manage to communicate locations in office buildings to each other, despite using zero-based counting in that context (or "ground-based counting"). I like the Sapir-Whorf undertones here!

"Intuition" means nothing more than one's un-/sub-/pre-conscious response to a situation based on prior experience. Education is all about providing new experiences and tools for dealing with new experiences.

"End users" are apparently the final arbiters of all matters, having reached that pinnacle of judgement on the basis of having no experience or training.

It reminds me of the scenario of an engineer presenting a design to management which drew on recently-published research results, only to have the presentation dismissed with the comment, "I've never heard of this stuff."

As for the posited great unwashed masses not being able to understand beginning with zero, that notion doesn't survive the following test:

How many years old is a child during her/his first year of life?

Most people of my acquaintance (included non-programmers) have no trouble understanding "Zero" as the answer.

(PS: OK, the attitude above is tongue-in-cheek, based on the numerous comments posted regarding EWD's curmudgeonly mode of expression. ;-)

As for the posited great unwashed masses not being able to understand beginning with zero, that notion doesn't survive the following test:

How many years old is a child during her/his first year of life?

Most people of my acquaintance (included non-programmers) have no trouble understanding "Zero" as the answer.
All right, I concede that "End users" can count from zero.

Now, could you explain me again what is the relation between one's age and the position of elements in a list?

I agree that end user intuition is probably that indexing should start with 1 and if I were creating a spreadsheet program I would index from 1. However, if I am creating a programming language I intend for it to be used by professional programmers. The great simplification that comes from indexing starting at 0 is worth the effort for a professional programmer to change his intuition. A small upfront cost pays off over one's career.

They have the big parties at 1999/2000 not 2000/2001. Which tells you that when they read a[2000] in a computer program they will assume that there are two thousand earlier enteries in the array,...

I don't buy this. There is no reason to come to this kind of conclusion when there is a much simpler explanation: 2000 is a nice big round number. That said, I think you do have a point in regards to counting out years, but that's because we are counting, not indexing. Natural numbers are for counting, and natural numbers do indeed start at zero. The argument here is about indexing (positioning) elements in an ordered sequence, which is classically the domain of ordinal numbers, not natural numbers. If I was told that x was the 2000^th element of sequence S, then you bet I would assume that there is 1999 elements before it, because it is the 2000^th.

I, of course can turn this argument around. If we start indexing at 0, then when asked the question: give me the 2000^th entry in the sequence, then I would have to index at 2001: we're off by one. If I had an sequence of size 2000, and I wanted the last element, I would have to index at 1999, again I'm off by one. The point is that these are positional questions (as is often, but not always, the case when dealing with indexes) and our thinking will be off by one when we use 0 based indexing.

They have the big parties at 1999/2000 not 2000/2001.

And the ones who do delay their turn-of-the-century parties to the *end* of **00 ought to be careful.

As to the main topic, I'm with Stan: "Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration." -- Stan Kelly-Bootle ...

Dijkstra never steered away from expressing opinions on religious matters. Not knowing him well enough, I wonder whether this was due to a perfectionist personality? Or was he using it as a teaching technique? Perhaps he felt that bringing emotions into the fray helped engage people in these matters, such that you could use that energy to teach more valuable lessons?

... of "Mikey" on the old Life Cereal commercials: "He hates everything!" I challenge anyone to find anything positive that Dijkstra has ever written about any computer language, for instance. I think he just enjoyed playing the role of curmudgeon. Not that I don't respect his contributions or his intelligence; I do, very much. But his negativity is so consistent and over the top that I have a hard time taking him seriously, even when I agree with him completely (which is often). I find it curious that someone with Dijkstra's views didn't try to design a general-purpose programming language himself, instead of just criticizing everything everyone else did. My guess is that he did (privately) and failed, and that that left him somewhat bitter about the entire enterprise.

Algol 60 in particular Dijkstra seemed to like. See EWD1284 especially, also EWD1298.
In these talks it seems Dijkstra had something positive to say about every language he mentioned, though he does have many complaints about most of them.

This is from his Turing award lecture in 1972, "The Humble Programmer":

The third project I would not like to leave unmentioned is LISP, a fascinating enterprise of a completely different nature. With a few very basic principles at its foundation, it has shown a remarkable stability. Besides that, LISP has been the carrier for a considerable number of in a sense our most sophisticated computer applications. LISP has jokingly been described as "the most intelligent way to misuse a computer". I think that description a great compliment because it transmits the full flavour of liberation: it has assisted a number of our most gifted fellow humans in thinking previously impossible thoughts.

He also was extremely positive about ALGOL 60 (and rightly so; it is a brilliant design with ideas decades ahead of anything else).

... but that LISP quote -- talk about a back-handed compliment! It sure sounds like deep down he didn't _really_ like LISP but felt he had to at least give it some props. "I think Lambda The Ultimate is by far the most intelligent way to misuse a blog." Hmmm...

Personality aside, the impression I get from reading Dijkstra is that his main obsession was in proving programs correct, and you can see why a very simple language with only a few carefully-chosen constructs would appeal to him. But he also wanted programs to be as efficient as possible, so you can see why he would prefer ALGOL to LISP (or at least the LISP of that time). I imagine he also liked PASCAL (anybody want to check?). Working at a high level of abstraction didn't seem to be something he really cared about much, beyond the "structured programming" level, of course.

In my opinion, well, yes and no.

Correctness, yes, and efficiency, also yes, in the sense of finding the best algorithm for solving a problem. Efficiency, in the sense of being as fast as possible, no. So, as for that being the reason to favor ALGOL over LISP, then no. My impression of his back-handed complement to LISP is that it had more to do with the use of LISP, rather than the language---Dijkstra was not a big AI fan. (Strong AI, from that viewpoint, is just kind of silly, and weak AI does not really mix with either provable correctness or elegant algorithms for a specific problem.)

I think [Dijsktra] just enjoyed playing the role of curmudgeon.

Considering the language landscape at the time Dijkstra was writing, I'd say he had some justification!

I find it curious that someone with Dijkstra's views didn't try to design a general-purpose programming language himself, instead of just criticizing everything everyone else did.

He did: the "guarded command notation". To the extent of my knowledge, he used it essentially unchanged from the mid-seventies on, at least until I saw his proof of Sylvester's line problem. (EWD1016, 1988; geeze, I suddenly feel old.)

In this day and age with large computer memories and heap-allocated garbage-collected objects, 4 bytes per array will not be missed in most computing tasks. I think it is better to start indexing at 1, and simply avoid the subtraction by not using the first element of the array.

Or even better use the first element to store the size of the array.

In most languages, arrays are tuples of a pointer to the data plus the length of the data region, so in some sense what you ask for is already done.

In C++, the length of the array is indeed stored at the beginning of the array, and that's the reason operator delete [] works; but it is not part of the standard.

I think it is better to start indexing at 1, and simply avoid the subtraction by not using the first element of the array.

This is a handy pattern! The only place I've seen it done was amongst Darius Bacon's simplifications in screenful #2. I was impressed that he removed a lot of distracting calls to 1- in such a simple way.

Darius has a knack for finding simple solutions that would somehow never occur to me. My favourite is awklisp representing conses as integers and having car and cdr each be not a function but an associative array. The integers even include type-tag bits and the the garbage collector cleans out the arrays.

We need to lure some people like Darius and Avi Bryant back onto LtU. I seem to recall that they're attracted by code snippets :-)

We need to lure some people like Darius and Avi Bryant back...

I agree.

Darius is my buddy... want me to talk to him? ;-)

Sure! Though I am sure he knows we miss him...

Not to detract from Darius' brilliant work, but I represented LISP cells this way in walk, which he references in the manual for his interpreter. The reason in both cases is simple: the only data structure Awk offers is the array!

That's right, I'd been impressed by walk before I wrote awklisp. walk uses the original awk dialect which doesn't even allow function definitions -- it was really neat how this still could implement Lisp cleanly with almost nothing to work with. There was no glory in doing it over in the more powerful new awk -- awklisp was all about razzing a commercial extension language we had to use at work that was so poorly implemented, you could do better even in awk.

Thanks for the kind words, guys.

You're using slot zero for metainfo when it's out-of-band (oob). But when zero is also a valid index, you can still keep metainfo in oob space for an array; making one index oob for this purpose changes little. You can reserve an arbitrary amount of space for oob metainfo before the array starts.

On the separate topic of sentinels (like nuls at ends of C strings): it's now always a good idea to use pointer plus length representation for strings of all flavors, except when you'e forced to speak to an API (eg standard C library calls) that require an end nul, and even then you can throw in trailing end nuls that get used by no one except retro APIs.

The reason to prefer pointer plus length representation is memory latency. It's prohibitively costly to touch memory often if unnecessary. Scanning to find an end nul after you've found it once is a waste of cycles. String heavy applications that use terminating nuls pay a heavy penalty in memory bus latency if strings are scanned in tight loops in many places in the code. So one would hope languages don't rely on sentinels for primitive strings.

Although this whole thread is predisposed to degrading to quibbles over semantics, I must ask, when is 0 'a valid index'? I have on my desk here an array of three pencils lined up. What do I have in my hand when I pick up the zeroth one? Is it even a pencil?

And I totally agree with you about pointer+length representation. In my world, the pointer points to the length, which defines the buffer that begins (1-indexed) right after. Easy and natural!

My world rocks.

“The reason programmers [...] tend to want to start counting with 0 is because old C habits die hard
[...] it makes no sense to begin counting with 0 in languages that do not have the concept of pointers”

Please note that:
• Zero-based indexing can be found in languages that have nothing to do with C, and in fact some of them predate C.
• Zero-based indexing is used in languages that have no notion (neither explicit nor implicit) of pointers at all, and semantically are very far from using pointers for referencing. (APL, J, and K are but one line of examples.)
Apparently, there are good reasons to prefer 0-based indexing other than pointers and C (just as there are reasons to prefer 1-based indexing). Some of them were mentioned in this thread.

Dijkstra is completely correct regarding the question he asked. It's just that the question Dijkstra asks is not the one programmers such as myself ask when dealing with arrays.

In fact, the quote mentions "sequences" and "subscript" which are terms normally associated with mathematical sequences, not with lists or arrays. However I believe that he really meant arrays.

Interesting that such a simple task as printing a comma-separated list is fiddly in many languages. Here're some decreasingly nice snippets:

(format t "~{~S~^, ~}" '(foo bar baz))

#(foo bar baz) do: [:x | Transcript show: x]
               separatedBy: [Transcript show: ', ']

L = ["foo", "bar", "baz"],
lists:foldl(fun(X,A) -> A++", "++X end, hd(L), tl(L)).

join sep (x:xs@(_:_)) = x : sep : join sep xs
join _   xs           = xs

Probably we could do better by expressing this as a fold and/or making it tail recursive but I find this short and nice enough.

join :: (Show a) => String -> [a] -> String

join sep [] = ""
join sep x  = foldr1 (\a b -> a ++ sep ++ b) $ map show x

I wonder if there's a commonly accepted combinator that shows explicitly that we're dealing with two cases, empty and full lists.

Something like

caseEmptyFull :: b -> ([a] -> b) -> [a] -> b

caseEmptyFull ifEmpty ifFull [] = ifEmpty
caseEmptyFull ifEmpty ifFull x  = (ifFull x)

We can then write

join sep = caseEmptyFull ""
                         (foldr1 (\a b -> a ++ sep ++ b) . map show)

That snippet seems to make it clearer that we're only passing full lists to foldr1 (and that we need to special-case empty lists); wrapping foldr1 might be better.

The map show bit makes the function less generic. My join had the polymorphic type: a -> [a] -> [a], which let us use in more places.

Your caseEmptyFull is similar to the maybe function. Actually every ADT can have a natural case function associated with, which is useful to express such idioms (for CADTs you have a natural build).

Actually a one-liner, non-tail recursive, definition using this case-like function could be:

list e f xs = case xs of {[] -> e; xs -> f xs}
join s = foldr (\x -> list [x] ((x:).(s:))) []

One could write the generic case in Template Haskell or use the one available in Morrow.

All number systems that originate in natural language, as opposed to sophisticed technical domains such as Arab number writing systems and imperial calendars, start at one, and you can tell the difference between the two by seeing how children count. Counting consists of establishing a bijective relationship between a set of counted objects; a counting sequence which starts with the beginning word, and then visits each successive counting word in turn; and then identifying a counting word that is the cardinality of the counted .

It makes as much sense to count from zero as from one: the only difference is that with 1-counting, the cardinality that you call is the same as the last counting word used in the relation, whereas with 0-counting it is the successor of this counting word. Why the children of no existing cultures do things this way, I leave to the anthropologists, amateur and professional, among you.

It makes as much sense to count from zero as from one

But you've said exactly why it doesn't: you have to add one at the end if you start from zero so counting from 1 is less effort. Counting and indexing are different things and even the English language makes a distinction between cardinal and ordinal numbers. So what makes sense for counting (starting at 1) isn't necessarily what makes sense for indexing.

PS Brits index storeys in a building starting with zero (though they call the zeroth floor 'the ground floor').

I am not entirely convinced that natural language avoids 0: before a meal (perhaps taken on the 1st floor of a restaurant — one floor above street level⁰), one might order:

"A glass of white as apéritif, please" = 1 wine + 0 pastis + 0 proseccos + ...

after a meal, should the hour be late, one might be more explicit:

"I wouldn't like any coffee, just the check, please"  = 0 coffees + ...

Furthermore, while it is true that in my experience athletes do not get a trophy for being 0th, a quick Google confirms that the Peano-style of champion 1st runner-up or winner 1st runner-up is not entirely unknown in natural language rankings¹.

[0] in the days before elevators and automobiles, the continental conceit was that the 1st floor, besides being first up from street level, was also ranked first as being the "best". Artists and servants lived up in the garrets, and had to climb (and haul water?) up all those flights of stairs, so lower was better. But one didn't want to be all the way down at ground level, which was the domain of horses and cows and goats (and their manure tips), warehouses for heavy goods, and (truly infra dig) shopkeepers. Now that we have elevators and excavators, the owners live on the tops of their buildings, garage their cars underneath, and have more room to keep profitable tenants in the glass-fronted spaces of the ground floor.

[1] we are looking for the place that is maximal in the sense that for any athlete Y, this athlete X has done as well or better than Y. Should the choice of 0 or 1 as an extreme depend upon whether we are adding, or multiplying, or merely ranking?

First order logic has quantification, but doesn't have cardinals or ordinals. Your argument that natural language "doesn't avoid zero" is specious, because zero is a *number*, and "nothing" doesn't involve numbers.

About as specious as an argument that first order logic is involved:

• how is one supposed to order "two beers, please"⁰ without any cardinals?
• what about
  

  champion → 0
  1st runner up → S0
  2nd runner up → SS0
  

  in the tournament case?

Maybe it's just indoctrination by the economists, but I don't believe I'm doing something fundamentally different when striking a dish from an basket to go from 1 to 0 than when going from 2 to 1. It may take an irregular form, but older IE languages can be even more irregular for small integers, having separate forms for 0,1, and 2 objects and only switching to the regular for the (not exactly transfinite case) of 3 and up.

That said, french does offer some support to quantification, in that I've been told that one uses a partitive because "I'll take the soup" implies one wants all of the soup in the house, where "I'll take some soup" indicates the rather more common situation of wanting only a part of it.

On the other hand, by the time an order goes to the kitchen (or is repeated as confirmation) it's been turned into a vector space of items with scalar multiplicities. That "some soup" implicitly converts to "soup, N times" when summarized on a ticket. Again, as a multiplicity, how is a ticket with no beer so different from a ticket with 1 beer or with 2 beers? (certes, an english pedant would have one say "a ticket without any beers", but the germans are perfectly happy saying "in heaven there's no beer"¹)

Bringing this all back to programming languages: with functions, we generally prefer to work with as coarse a topology on the domain as possible (minimizing the case analysis necessary, which improves calculation of properties at compile time and avoids branching at run time). This also holds true for the semantics functor; given an expression to translate, it will be much smoother if our syntax expresses 0, 1, or multiple values in a natural way.²

[0] I am told the most important series of phrases to learn in any language is

• "two beers, please" (nb. the accompanying hand signal varies with geography),
• "my friend will pay" (pointing is usually acceptable here)
• "where are the toilets?".

[1] hence we'd better drink it here

[2] why, then, are infix expressions so popular? Perhaps it's the limited dimensionality of the problem: infix offers arities of {0,1,2} and thereby gets up to arbitrary trees, with names extending that to graphs. But unless one can profitably modify the meaning of any facets in those graphs, we only care about the edges.