Of the total code base of these boxes, what percentage is different? 0.1%, maybe? Yet that one percent makes all the difference between the two sites.

It could be argued that these LAMP boxes have “too rich API’s” and that it should be trimmed down to just the bare necessities. Somehow, though, I’d think it’d be harder to do this trimming down and rebuild your Linux box “just for that single site” with simple building blocks all the way up from the kernel (I’m a systems thinker, so I look at systems )…

About 0-vs-1 indexing: you made a point about the C family. That doesn’t mean it’s a valid point across all languages.

Oh - and please keep your ad-hominem attack mode in check. Calling people stupid is at best counterproductive in *any* discussion

It’s not a matter of taste. If C had used 1-indexing, then a pointer to an array would have had to point to the element preceding the array … which would have been a different address depending on the type of the pointer (so, e.g., casting int* to char* would have required runtime arithmetic). This obviously would have been insane. Java is derived from and is supposed to resemble C, so it would obviously have been a very bad idea to switch from 0-indexing to 1-indexing, and of course interfacing with the OS or C extensions would have been error-prone. These are just the most obvious reasons why 0-indexing is /objectively/ superior, for those languages at least. (There are numerous other cases where it’s useful for “index of” and “offset to” to be the same thing.)

Ironically, in Ruby you can say array[-1], which, /for arrays/, has the same semantics as (is /defined/ as) array.last (but not so for other objects, which makes it non-redundant), whereas in Java you have to say array.get(array.size() - 1) (or getLength instead of size for ArrayList, sigh), which /is not/ defined as accessing the last element and isn’t recognizable as such, since the /calculated/ index is an integer just like any other. Aside from the fact that it takes slightly more space and time (the

Now, that interface might be larger than you’d wished for, especially if you are writing some code that you hope will be reused by others. In Smalltalk, then comes the final “refactoring”, categorizing the various parts of your interface. In theory, you could categorize your interface into “basic” and “advanced” (and “private”, of course) categories, but more often the categorization is more functional (”accessing”, “updating”, …). In either case, this goes a long way towards making class interfaces more approachable to developers that aren’t completely familiar with the class.

In any case:

This is not an issue of explsing the implementation. A List is a collection of objects, held in some defined order, which can be numbered 0 to n-1 for a List of size n.

Or, as you say, as 1..n. Which is where you start getting the benefit of intention-revealing selectors–if you code a stack or a FIFO, just operating on the list by sending it #first, #removeLast, etcetera, you abstract away from the underlying implementation and towards the reader of your code, making clear what you intended (instead of what the author of the underlying library code you’re using implemented).