Yukon and .NET 2.0 Wishlist

[Guest]

good point!

we have it now... sooo... why change it

do u really think that MS are going to change arrays to 1 based..??? in .NET?

i take it that you guys who want it to change have never had to upgrade code from version to version before?

 

[Daniel Pratt]

Youi like it because you are used to it. Legacy.

You know, . (if that's your real name), it seems that your trying to
persuade readers that 1-based is far superior to 0-based, which is fine. On
the other hand...I don't think insulting people, telling people they are
"afraid of change", and/or telling people what they think and why they think
it is going to help you get your point across. Quite the opposite, I'm
afraid.

Although I dabble in other languages and although I will use C# if given the
choice, VB6 coding is what I've been paid to do for the last 5-6 years
(basically my entire professional career, so far). Point being I don't have
any particular attachment to 0-based arrays. And yet I don't *care* whether
arrays in language X are 0-based, 1-based, 100-based, or -1238-based *as
long as they are "based" the same*. What VB6 will make you thankful for is
that in .NET arrays are *always* going to be 0-based. In VB6 most of my
array iterations look like this:

For i = LBound(someArray) To UBound(someArray)
...
Next i

Apologies for posting VB6 code to this list ;-)

Another thing that comes to mind is that there's something to be said for
legacy. Programmers should, in general, know what to expect from a new
language. Of the major languages .NET programmers are likely to have
experience with (C++, Java, VB) only VB isn't 0-based. And that's because it
isn't *based* at all. If .NET programmers have an expectation, based on
prior experience, about what "base" arrays should be, .NET meets that
expectation.

Regards,
Dan

 

[William Stacey]

Good point Daniel. And thanks for the vb6 sample. I remember that now and
shuttered a bit.

 

[Austin Ehlers]

Just because something is legacy doesn't mean it's wrong or bad. And
if it's one-based, that means there are two conditional tests in
normal for(..) loops, one for less-than, and one for equal-to. That
adds complexity, not usefulness.

3 decades of a standard array access need not be changed just for a
few handfuls of "programmers".

Zero-based comes from how C (and C#) accesses array elements. It
takes the starting address, and adds the pointer size times the index.
Mathematically:

element=startAddress+(PointerSize*index);

If arrays were one-based, all the under-the-cover array access methods
would have to subtract one from every call. Every single array access
would have another instruction to do.

Austin

 

[Jon Skeet [C# MVP]]

Just because something is legacy doesn't mean it's wrong or bad. And
if it's one-based, that means there are two conditional tests in
normal for(..) loops, one for less-than, and one for equal-to. That
adds complexity, not usefulness.

I don't think it would actually end up as two conditional tests - it
would end up as one processor instruction on most processors, I
believe.

Zero-based comes from how C (and C#) accesses array elements. It
takes the starting address, and adds the pointer size times the index.
Mathematically:

element=startAddress+(PointerSize*index);

If arrays were one-based, all the under-the-cover array access methods
would have to subtract one from every call. Every single array access
would have another instruction to do.

I was considering this earlier. The smart thing to do instead of that
would be to store the address of the array data -1 element, and then
access it as if it were 0 based.

I don't think there needs to be much performance problem - but I still
don't think it should be done, because I prefer arrays to be 0-based in
terms of mathematical elegance.

 

[Guest]

Yes it is you zero based array zealot!!

You know, . (if that's your real name), it seems that your trying to
persuade readers that 1-based is far superior to 0-based, which is fine. On
the other hand...I don't think insulting people, telling people they are
"afraid of change", and/or telling people what they think and why they think
it is going to help you get your point across. Quite the opposite, I'm
afraid.

Although I dabble in other languages and although I will use C# if given the
choice, VB6 coding is what I've been paid to do for the last 5-6 years
(basically my entire professional career, so far). Point being I don't have
any particular attachment to 0-based arrays. And yet I don't *care* whether
arrays in language X are 0-based, 1-based, 100-based, or -1238-based *as
long as they are "based" the same*. What VB6 will make you thankful for is
that in .NET arrays are *always* going to be 0-based. In VB6 most of my
array iterations look like this:

For i = LBound(someArray) To UBound(someArray)
...
Next i

Apologies for posting VB6 code to this list ;-)

Another thing that comes to mind is that there's something to be said for
legacy. Programmers should, in general, know what to expect from a new
language. Of the major languages .NET programmers are likely to have
experience with (C++, Java, VB) only VB isn't 0-based. And that's because it
isn't *based* at all. If .NET programmers have an expectation, based on
prior experience, about what "base" arrays should be, .NET meets that
expectation.

Regards,
Dan

 

[Austin Ehlers]

I don't think it would actually end up as two conditional tests - it
would end up as one processor instruction on most processors, I
believe.

Yeah, I should have been more specific. I was speaking from a
literal, not processor, position. A single test (less-than) is
simpler to understand and read through than two different tests.

I was considering this earlier. The smart thing to do instead of that
would be to store the address of the array data -1 element, and then
access it as if it were 0 based.

I don't think there needs to be much performance problem - but I still
don't think it should be done, because I prefer arrays to be 0-based in
terms of mathematical elegance.

I'm sure that the practical performance difference of an additional
call is nearly neglible (and if perf. is a must, just use pointers).
Making arrays one-based would throw a whole bunch of framework code
out of whack, as it assumes 0-based.

Austin

 

[Jon Skeet [C# MVP]]

Yes it is you zero based array zealot!!

Yes what is what? Please quote which part of a reply you're actually
addressing, otherwise it's pretty tricky to work out what you're trying
to say.

 

[malcolm]

I see I've started a big debate. Jon, let me make these points first.
To me, I don't think this will or should ever be changed to 1 based
due to the huge history of zero based logic built into computers. I'm
merely pointing out that I think that was a mistake and if it were up
to me I would really consider the change in a new language such as c#
(too late now). Excuse me if I sound a little contradicting with the
whole .NET 2.0 thing about this one, I was just spilling my thoughts
late one night

I think this really stems from they way memory works. Bytes start at a
zero register and increment from there which makes sence I suppose.
Early in the game there was mainly assembly languages (which was very
tied to hardware) which evolved more and more to higher level
languages. I'm merely suggesting that the better way for high level
languages is 1 based.

Let me also re-iderate that most arguments I've heard toward zero
based arrays are from people with a strong c++ (or other zero based
language) background. You (as many) need to make a distinction with
what you want and are used to and with what is the true better way.

Let me explain; Would you agree that programming in general over the
last twenty years is becoming more and more high level and abstract? I
consider this (as most do i think) for the most part a good thing
(there are always exceptions: i.e. drivers, etc...). If you agree with
this statement, then high level programming should match the real
world, like say an english sentence:

I would like to get the third apple:
equates to
AppleObject myApple = myApples[3];

In zero based, it would be:
I would like to get the third apple:
equates to
AppleObject myApple = myApples[2];

Another example:
Do you have the last apple?
equates to
if (myApple.Value == myApples[myApples.Count].Value)

In zero based, this would be:
Do you have the last apple?
equates to
if (myApple.Value == myApples[myApples.Count-1].Value)

This is all really not that big of a deal, but for programming to
really take shape over the next 50 years and open up some crazy
possibilities we have to make our high level languages pimp and
streamlined!

-dave

 

[Jon Skeet [C# MVP]]

Let me explain; Would you agree that programming in general over the
last twenty years is becoming more and more high level and abstract?

Yes, generally - although one of the problems is that people don't
bother to think/find out about what's happening in the layer beneath
their immediate code. That's a problem because unless you know to
*some* extent how things like the JIT compiler, garbage collector, etc
work, you're not going to be able to write as good code. While you
don't need to know the details, a general idea of the various layers
involved is a good thing, IMO.

I consider this (as most do i think) for the most part a good thing
(there are always exceptions: i.e. drivers, etc...). If you agree with
this statement, then high level programming should match the real
world, like say an english sentence:

No, I don't agree that programming languages need to necessarily follow
natural languages. There will always be far too many exceptions for
that to be true anyway, and anyone trying to think of programming
solely in "real world" terms is going to have a problem - for a start,
they're going to try to add a fourth apple, and find that arrays are a
fixed size...

I would like to get the third apple:
equates to
AppleObject myApple = myApples[3];

Again though, you're implying that because *some* real world examples
are naturally 1-based, that *all* are, and I just don't believe that's
true. See my example of mapping two dimensions to one, for instance,
where 0-based arrays make things much simpler than 1-based, just
because being able to add an array index to another (and multiply them
etc) works better in a 0-based system.

This is all really not that big of a deal, but for programming to
really take shape over the next 50 years and open up some crazy
possibilities we have to make our high level languages pimp and
streamlined!

I really don't think changing from 0-based to 1-based arrays would in
any way "streamline" them, I'm afraid.

 

[Zürcher See]

It's very funny. Still today there is people that have problem with the
zero, the most important matematical invention.
The zero was found by indian about 1000 BC, and introduced in europa in 1200
AD from Fibonacci.
Already to the age there was people against the new numeric system.
For example in Venice in 1300 AD it was emanated a law that it forbade the
new numeric system.
I hope that the new languages will use the roman enumeration

array, array[II], ... , array[VII], ... , array[DCCLIIX], ... ,
array[MID], .. , array[MMIV]

Isn't it very beautiful?

 

[Guest]

funy

Notice how youre idea starts at I (one)

 

[Jon Skeet [C# MVP]]

Notice how youre idea starts at I (one)

Yes, it would have to - because the Romans didn't know about zero, so
didn't have a numeral for it, IIRC. (Somewhere I've got a book about
the "history of nothing" but I can't find it immediately...)

 

[Cor]

Hi Malcolm,

Although I agree with the facts it sounds to me the same as telling that
everybody has to talk the same language.

I also agree that. Chinese of course because that is spoken by the most
people on Earth so it should be the best.

Just my 2 Eurocents

Cor

 

[malcolm]

To me, the number zero implies "nothing" as in "does not exist" and
yet in programming a "zeroth" element in an array really means the
"first" element. Why can't anybody see the irony in that statement.

The "zero-based" fanatics will probably be quick to point out that
many situations work out better in zero based logic. Well, the truth
is both cases can handle any situation. I merely think we made a (very
minor but lasting) mistake when computers were first created. We
should have started from the very heart of memory and hardware as one
based (as it's truly arbitrary). Then all this would be a non-issue as
everything would be one-based... period. I think 1000 out of 1000
will agree that it's too late for such a change now, including
"one-based" supporters like myself.

Everyone is actually correct in this post since either way works
effectively. Zero based is slightly more effecient due to the
underlying kernal and hardware, thus we're stuck in a zero-based
programming world. The fact VB supports one-based is probably making
it less efficient, but we all know VB didn't get to where it is by
squeezing out every once of speed.

My point all along really was that we got it wrong, but it's not that
big of a deal and we'll all live.

If at least some of the zero based people would admit that we did get
it wrong then we could move forward, cuz we cannot change it so it's a
moot point really.

Dave

p.s. Dan even though I'm on your side, I must point out your code
needs optimizations. But I'm assuming you know this and merely used
this as an example:

For i = LBound(someArray) To UBound(someArray)
...
Next i

should be written as

dim lngLBound as long
dim lngUBound as long

lngLBound = LBound(someArray)
lngUBound = UBound(someArray)

For i = lngLBound To lngUBound
...
Next i

Unforunately, VB will execute UBound and LBound on every iteration.
The reason it does this is because it allows these values to change
inside the for loop. Don't believe me, run a simple test running
10,000 loops and time the differences...

 

[Jon Skeet [C# MVP]]

If at least some of the zero based people would admit that we did get
it wrong then we could move forward, cuz we cannot change it so it's a
moot point really.

But I don't agree with the idea that it *is* wrong. As I've said
before, using a base of zero makes various things much easier. I gave
an example before of mapping (x, y) to a single index. That is exactly
what happens with multi-dimensional arrays. It's just a nice
mathematical fact that 0+x=0 and 0*x=0. It's not useful having 1*x=x
for arrays, whereas the previous two properties *are* useful.

Would you also suggest that byte values should go from 1-256 instead of
0-255 as well? (Actually, you never answered my point about null value
types in the first post you made, which suggested that you believed a
byte should have 257 possible values instead of 256.)

Computing is based more on maths than on shopping lists. Ask a
mathematician where the origin is and he'll tell you it's at (0,0) (or
whatever, depending on the dimensions) - not (1,1).

If we're talking about mistakes that are far too late to remedy, it
would probably be more accurate to say that mankind makes the mistake
of being 1-based in its counting.

 

[Daniel Pratt]

Hi malcom,

p.s. Dan even though I'm on your side, I must point out your code
needs optimizations. But I'm assuming you know this and merely used
this as an example:

For i = LBound(someArray) To UBound(someArray)
...
Next i

should be written as

dim lngLBound as long
dim lngUBound as long

lngLBound = LBound(someArray)
lngUBound = UBound(someArray)

For i = lngLBound To lngUBound
...
Next i

Unforunately, VB will execute UBound and LBound on every iteration.
The reason it does this is because it allows these values to change
inside the for loop. Don't believe me, run a simple test running
10,000 loops and time the differences...

Yes, it's a question of coding efficiency vs. operational efficiency. I
figured if I didn't pare it down to the minimum "someone" would accuse me of
making it more complex than necessary. Given my argument, I didn't
anticipate being accused of the reverse ;-)

Regards,
Dan

 

[Guest]

Why should it be less effiecient, the compiler can map the start element to
zero if its easier for it. Just like it wraps IEnumerator with foreach.
Just because WE code it as 1 starting, doesnt mean its stored that way.
That excuse is just one thing, pure bs.

 

[Guest]

the first coordinate as you are so fond of, is the FIRST coordinate,
regardless of its value.

 

[Guest]

Since we are at the HIGH level, why should we care about the implementation
at the compiler level and runetime because thats why we have those, so WE
DONT HAVE TO CARE.