This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: 1's or 0's?
Feed Title: Travis Griggs - Blog
Feed URL: http://www.cincomsmalltalk.com/rssBlog/travis-rss.xml
Feed Description: This TAG Line is Extra
My first programming language was FORTRAN77 (self taught with lots of mentors). In that world, you used 1 to refer to the first element of an array. This of course is natural. After doing that for a while, I got a chance to teach myself both Smalltalk and C. Smalltalk did the Fortran thing: the first element of an array is 1. But as we all know, C and many other languages start at 0.
At the time, I didn't have much use for C, and didn't learn much of it but the basics. Smalltalk was just much more exciting that increment char* pointers. I participated in the same rip sessions of "0 based languages". I was a Smalltalker, a member of the "1 crowd".
Eventually, I did learn more C, a lot more C. And for certain types of problems, I came to really appreciate the 0 based access, and porting said algorithms back to Smalltalk made me grimace. -/ 1 all over the place.
What I don't get, is why a language has to be 0 based or 1 based? Why can't it be both 1 and 0 based? I can suppose it's because in a language like C, where you use syntaticly coded gobbly gook (e.g. 1) to get most stuff done, your infix characters are precious and supporting to access models in parallel is just not worth it.
But what's our excuse in Smalltalk? We benefit from this principle called uniformity; everything gets done via message sends. We use a message for array access and setting, not additional syntax. Why not just introduce zero based analogs to the at: and at:put: messages? The tricky part (I think) is coming up with a good method name for these zero based versions of at:. You want something that communicates its difference, but is also short and terse. So, zeroedAt:(put:) are probably not acceptable. We have lots of two letter prepositions (and most are positional), would any of them work? What would you call such a method?
I'm almost a day behind now.
As an aside, for the performance weenies, adding a translated primitive to the VM for said two methods would be easy, and it's likely to run at least one instruction faster than the at: counterparts.