The Pebble in the Ruby Shoe

[Chad Perrin]

Perl's misfeature is pretty different - it's a global rather than a
per-array thing. Being able to say "this particular array has indices
-10 -> 10 is considerably more useful than saying "every array starts
at -10"

News to me. Would you point me at more information on the topic, please?

 

[M. Edward (Ed) Borasky]

I never used ALGOL, but:

http://en.wikipedia.org/wiki/ALGOL_58
Both IAL and ALGOL 60 allowed arrays with arbitrary lower and upper
subscript bounds, and allowed subscript bounds to be defined by
integer expressions.

I wonder how C got saddled with a fixed lower limit of 0 then. It must
have been a simplification somewhere in the chain from Algol - CPL -
BCPL - B - C.

http://www.cs.virginia.edu/~mpw7t/cs655/pos2.html
ALGOL 68 was designed to be an improvement upon ALGOL 60. In ALGOL 60,
arrays could be multi-dimensional, they could be dynamically sized,
and their lower bound index could be non-zero [1].

Algol 68 was a truly marvelous language that somehow never caught on.

 

[Giles Alexander]

I wonder how C got saddled with a fixed lower limit of 0 then. It must
have been a simplification somewhere in the chain from Algol - CPL -
BCPL - B - C.

In C the expression array[n] is actually just syntactic sugar for
*(array + n). Literally. I haven't tried in years, but the following
is supposed to be legitimate: n[array]. Great for obfuscating code.

If that's how you're going to perform array lookups, then your array
indices have to start from 0.

Giles

 

[kevin cline]

Ruby aims to be a human friendly programming language that embodies the
principle of least surprise...

The pebble in the Ruby shoe is the counter-intuitive use of indexing of
elements of arrays, strings, etc., from 0 to n-1 instead of the more
natural 1 to n.

With 50+ years of collective experience, it seems clear that zero-
based arrays lead to the simplest code.

 

[Ronald Fischer]

In C the expression array[n] is actually just syntactic sugar for

*(array + n). Literally. I haven't tried in years, but the following
is supposed to be legitimate: n[array]. Great for obfuscating code.

This indeed works, and consequently funny variations such as
(n1-n2)[n2+array] work too. It is obfuscating not so much because
it were not easy to understand, but because we simply are not used to=20
see it written that way (because other languages usually do it in=20
the other way around).

To contrast with, the IMO most unpleasant way of approaching the index=20
origin was done in APL. There, you could set the system variable _IO=20
to either 0 or 1 (no other value accepted), which rules whether array=20
the index of *any* array is from now on counted from 0 or from 1.=20
True, you *could* localize this setting in a function, but at least=20
in original APL (I don't know about APL2), these were not truly
"local" variables like in Ruby, but more like those "local global"=20
variables you would for example declare in Perl by writing=20
'local $v=3D....;', with the consequence that they the change to _IO
would be visible in all functions called from within the function
which had "locally" reset the index origin. This has the consequence
that if you write *any* reusable function for APL (such as a library),=20
you must use the value of this variable for indexing. For example,
in order to access the Nth element of an array A, you would write
something like A[N+_IO-1].

BTW: Though I - like most programmers - find it most convenient counting
arrays from zero, there are cases where I would find it more natural
if I could choose the upper and lower bound of an array by myself (as
it is done in languages such as Ada). Such an approach would work well
in a statically typed language (where you can in principle look up
the variable declaration), but would make understanding a program=20
unnecessarily hard in dynamic languages such as Ruby.

Ronald

 

[MenTaLguY]

--=-Pb9VgmhjXuZ57EpUd+f4
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

To contrast with, the IMO most unpleasant way of approaching the index=20
origin was done in APL. There, you could set the system variable _IO=20
to either 0 or 1 (no other value accepted)

Perl has this too, though it's called $[.

Obviously, it isn't normally used and people assume the default value of
0.

-mental

--=-Pb9VgmhjXuZ57EpUd+f4
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBGncliSuZBmZzm14ERAp9MAKCy/dXApskEeHYUYpxtdXvDBUn76wCfS4fA
kq57UUeQVXyQh0D6VyEaeg4=
=NKcr
-----END PGP SIGNATURE-----

--=-Pb9VgmhjXuZ57EpUd+f4--

 

[MenTaLguY]

--=-SirkJ5xz4/OgHr5Srjzu
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

=20
With 50+ years of collective experience, it seems clear that zero-
based arrays lead to the simplest code.

That's been my personal experience, too -- pretty much the only thing
1-based indices make simpler is getting the last element of an array
given its size; everything else seems to get more complex.=20

-mental

--=-SirkJ5xz4/OgHr5Srjzu
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBGncnOSuZBmZzm14ERAma0AKCOYvSZU7WOSJFLtB3rikbjh/+S9QCfbLxf
v13pQSvk1ro4X5AEUqefsPU=
=FQD9
-----END PGP SIGNATURE-----

--=-SirkJ5xz4/OgHr5Srjzu--

 

[Ronald Fischer]

To contrast with, the IMO most unpleasant way of=20

approaching the index=20

origin was done in APL. There, you could set the system=20 variable _IO=20
to either 0 or 1 (no other value accepted)

=20
Perl has this too, though it's called $[.
=20
Obviously, it isn't normally used and people assume the=20
default value of
0.

True! It seems that the Perl community (reasonably) assumes
that whoever fiddles with $[, so everyone assumes it to be
0, while in the APL world it was more common to expect that everyone
might change _IO...

Ronald

 

[Robert Dober]

That's been my personal experience, too -- pretty much the only thing
1-based indices make simpler is getting the last element of an array
given its size; everything else seems to get more complex.

I do not like categorical statements, but this one might be the
exception that confirms the rule.
+1 (or was that +0
Robert

 

[Michael P. Soulier]

I do not like categorical statements, but this one might be the
exception that confirms the rule.
+1 (or was that +0

Lets not forget also that doing things for the sake of being different help no
one. I for one must work in multiple languages. I still haven't forgiven Matz
for the whole, "0 is true" thing. ;-)

Mike

 

[Robert Dober]

Lets not forget also that doing things for the sake of being different help no
one. I for one must work in multiple languages. I still haven't forgiven Matz
for the whole, "0 is true" thing. ;-)

That is the single best feature of Ruby once you got used to it --
with "" is true!!!
IMHO of course.
Robert

 

[M. Edward (Ed) Borasky]

That's been my personal experience, too -- pretty much the only thing
1-based indices make simpler is getting the last element of an array
given its size; everything else seems to get more complex.

-mental

Well ... the reason the first major programming language, FORTRAN, used
1-based indexing is that it was designed for scientific computing, which
uses matrices extensively. And a matrix in a textbook or research paper
almost always has row and column indices ranging from 1 to N. So ... one
of the things 1-based indexing makes simpler is thinking about matrices.

Assembly language programming, at least on binary machines, is a lot
more natural with 0-based indexing, since that's the way the hardware is
laid out.

 

[M. Edward (Ed) Borasky]

Lets not forget also that doing things for the sake of being different help no
one. I for one must work in multiple languages. I still haven't forgiven Matz
for the whole, "0 is true" thing. ;-)

Mike

I haven't forgiven Scheme for "nil is true" either!! That's just *so*
wrong to a Lisp 1.5 programmer.

 

[Robert Dober]

I haven't forgiven Scheme for "nil is true" either!! That's just *so*
wrong to a Lisp 1.5 programmer.

Much more difficult to see the benefits of this, but I am listening

R.

 

[John W. Kennedy]

With 50+ years of collective experience, it seems clear that zero-
based arrays lead to the simplest code.

....unless there is a lot of exposure of nominal index values to the end
user, in which case the additional effort of doing that may incur more
complexity than is saved by using 0-origin internally.
--
John W. Kennedy
"The bright critics assembled in this volume will doubtless show, in
their sophisticated and ingenious new ways, that, just as /Pooh/ is
suffused with humanism, our humanism itself, at this late date, has
become full of /Pooh./"
-- Frederick Crews. "Postmodern Pooh", Preface

 

[John W. Kennedy]

Well ... the reason the first major programming language, FORTRAN, used
1-based indexing is that it was designed for scientific computing, which
uses matrices extensively. And a matrix in a textbook or research paper
almost always has row and column indices ranging from 1 to N. So ... one
of the things 1-based indexing makes simpler is thinking about matrices.

Assembly language programming, at least on binary machines,

....all the decimal machines I can recall, too...

is a lot
more natural with 0-based indexing, since that's the way the hardware is
laid out.

PL/I implementations have historically regarded the address of an array
as being where the (0, 0, 0...) element would be, even if one doesn't
exist, to reconcile these two.

 

[Lloyd Linklater]

Lets not forget also that doing things for the sake of being different
help no one. I for one must work in multiple languages. I still haven't
forgiven Matz for the whole, "0 is true" thing. ;-)

but but but...

The original idea of zero as true, if memory serves, is that a function
can return a result based on whatever it was doing. It was assumed that
there was one way to get everything to run right but many ways to fail.
SO, if you have zero as the true and everything else as both an
pass/fail indicator AND telling you just what the problem was, then true
= zero makes a good deal of sense.

my $0.02

 

[MenTaLguY]

--=-HS2ndRCqSXshbv8qa92D
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

That is the single best feature of Ruby once you got used to it --
with "" is true!!!

One of the biggest advantages to this is that it makes || and ||=3D
actually useful for non-boolean stuff (by way of contrast, Perl has the
same operator behavior, but it's not as useful when common valid values
can be false).

-mental

--=-HS2ndRCqSXshbv8qa92D
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBGnlYgSuZBmZzm14ERAjtIAKCcsLb20aHzmMS1tRDxJzFJgHOHYQCfdkAn
1Omv/xzR4xe6et/aI4JRvhI=
=pDgV
-----END PGP SIGNATURE-----

--=-HS2ndRCqSXshbv8qa92D--

 

[Robert Dober]

One of the biggest advantages to this is that it makes || and ||=

and one of its biggest dangers too, I wonder how much time has been
spent in looking for "Why has my already (with false) initialized
variable been overwritten?"
I am *not asking* that false evaluates to true, but I suggest that

x=false
x||=42
x --> false

or even
x ??= 42
for that semantics.

Robert

 

[William James]

The pebble in the Ruby shoe is the counter-intuitive use of indexing of
elements of arrays, strings, etc., from 0 to n-1 instead of the more
natural 1 to n.

You're saying that it is self-evident that indexing
should start at 1. Remember the definition of "self-evident":

self-evident, adj. Evident to one's self and to nobody else.

Let's say you're programming in a low-level language.
If A is the address of an array, and S is the size
in bytes of an element, what's the address of the
Nth element?

If indexing is 0-based:
A + N*S

If indexing is 1-based:
A + (N-1)*S

Can you tell which is simpler?