473,320 Members | 1,945 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

Yukon and .NET 2.0 Wishlist

Here are a couple of dramatic requests that I've always thought should
be implemented.

1) Uniform null. I wish .NET would implement a uniform value for nulls
accross the board. Even into the database (especially with some of the
hype about what can be done in Yukon). Before passing this off as an
absurd statement, it could be done and would simplify code
dramatically. To me, it's one of those things that people just simply
don't think this could ever be solved so there is simply no demand for
it. I mean, we did research on different methods on how to solve this
and found many interesting approaches. One guy wrote reference type
classes for each datatype and added an IsNull property. This kills
effeciency though obviously. What we do is use int.MinValue,
DateTime.MinValue, etc to represent a null value. DBNull.Value's have
to be handled in a specific way as well as null's etc... I know to
solve this would be extremly difficult and may come at a cost, but
personally, I don't think a high level language (such as VB.NET, C#,
VB 6.0, etc) should have to deal with this stuff. This should be
handled at the assembly level. Maybe each value type could double in
storage space (since hardware and memory is becoming cheaper) and the
first bit could represent a null value. Or the memory manager could
store the bit on the stack when the variable is declared. Yada Yada
Yada...

2) For many of the same reasons as #1 (#1 is kind of a subset of #2),
why can't SQL Server and .NET have uniform types. This is really
pushing it now (I know) and probably will not happen anytime soon
(although Yukon may make steps towards this). I know this is a
drastic shift and would cause a lot of stuff to break, but it would be
the right thing to do and make code have less bugs accross the board.
For example, decimal, money, currency, DateTime, SmallTime, bit,
boolean and especially nulls (#1).

3) Automated creation of Solution Build Order built into Visual
Studio. The more I think about it, the more I'm convinced that this
would be a pretty easy "Add-On" to write. Microsoft refused to do this
and would have made many peoples lives a whole lot easier I think. In
short what this would mean is that you should be able to add 15
projects to a solution and then click on a button and it figures out
your build order depending on the references of each project. Visual
Studio includes a Solution Build Order but the problem is that you
have to set this list manually. And whenever there is a change (such
as adding a new project or a reference inside a project changing), you
have to update this list accordingly. The same even hold's true for
reference paths inside of a single project if you have (this only
becomes an issue if you need to have multiple reference paths inside
that project). I do see the need to allow the user to manually do it
also, but this would be a huge addition I think.

4) All arrays should start at 1! This is something (to me) that is
legacy and won't go away (probably ever). There really is no need for
zero based arrays. We are in high level languages now, so we should
be dealing with logic! I think the reason so many people stick to the
notion of zero based arrays is that it makes them feel like part of
the "c++" crowd and not part of the "VB" crowd, where many people
think c++ requires more skills. (I really do think this is the biggest
reason). Anyway, my thougths on this have nothing to do with any
particular language. I'm skilled in c#, VB.NET, VB 6.0 and C++ 6.0 so
I'm not biased at all. I mean, let's face it: If an array has 3 items
in it, then the Count = 3 and you can reference the last item like
this array[array.Count] which is completely logical to me.

Dave
Nov 15 '05 #1
52 2807
malcolm <ch********@yahoo.com> wrote:
Here are a couple of dramatic requests that I've always thought should
be implemented.

1) Uniform null. I wish .NET would implement a uniform value for nulls
accross the board. Even into the database (especially with some of the
hype about what can be done in Yukon). Before passing this off as an
absurd statement, it could be done and would simplify code
dramatically. To me, it's one of those things that people just simply
don't think this could ever be solved so there is simply no demand for
it. I mean, we did research on different methods on how to solve this
and found many interesting approaches. One guy wrote reference type
classes for each datatype and added an IsNull property. This kills
effeciency though obviously. What we do is use int.MinValue,
DateTime.MinValue, etc to represent a null value. DBNull.Value's have
to be handled in a specific way as well as null's etc... I know to
solve this would be extremly difficult and may come at a cost, but
personally, I don't think a high level language (such as VB.NET, C#,
VB 6.0, etc) should have to deal with this stuff. This should be
handled at the assembly level. Maybe each value type could double in
storage space (since hardware and memory is becoming cheaper) and the
first bit could represent a null value. Or the memory manager could
store the bit on the stack when the variable is declared. Yada Yada
Yada...
So what you're saying is that a byte should no longer be able to hold
256 different valid values? That's going to make things interesting
when reading files, etc...

Or were you proposing that the byte type no longer takes up only 8
bits?
4) All arrays should start at 1! This is something (to me) that is
legacy and won't go away (probably ever). There really is no need for
zero based arrays.
There's no need for one-based arrays either, IMO.
We are in high level languages now, so we should
be dealing with logic! I think the reason so many people stick to the
notion of zero based arrays is that it makes them feel like part of
the "c++" crowd and not part of the "VB" crowd, where many people
think c++ requires more skills.
No, I think it's far more to do with there being lots of C/C++/Java
developers using C# who think more naturally in terms of 0-based
arrays. I know I do...
(I really do think this is the biggest
reason). Anyway, my thougths on this have nothing to do with any
particular language. I'm skilled in c#, VB.NET, VB 6.0 and C++ 6.0 so
I'm not biased at all. I mean, let's face it: If an array has 3 items
in it, then the Count = 3 and you can reference the last item like
this array[array.Count] which is completely logical to me.


Of course, you can use the Array class to have a lower bound of 1 if
you really want.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 15 '05 #2

"malcolm" <ch********@yahoo.com> wrote in message
news:4f**************************@posting.google.c om...
Here are a couple of dramatic requests that I've always thought should
be implemented.

1) Uniform null. I wish .NET would implement a uniform value for nulls
accross the board. Even into the database (especially with some of the
hype about what can be done in Yukon). Before passing this off as an
absurd statement, it could be done and would simplify code
dramatically. To me, it's one of those things that people just simply
don't think this could ever be solved so there is simply no demand for
it. I mean, we did research on different methods on how to solve this
and found many interesting approaches. One guy wrote reference type
classes for each datatype and added an IsNull property. This kills
effeciency though obviously. What we do is use int.MinValue,
DateTime.MinValue, etc to represent a null value. DBNull.Value's have
to be handled in a specific way as well as null's etc... I know to
solve this would be extremly difficult and may come at a cost, but
personally, I don't think a high level language (such as VB.NET, C#,
VB 6.0, etc) should have to deal with this stuff. This should be
handled at the assembly level. Maybe each value type could double in
storage space (since hardware and memory is becoming cheaper) and the
first bit could represent a null value. Or the memory manager could
store the bit on the stack when the variable is declared. Yada Yada
Yada...
There is supposed to be a generic type, Nullable<T> I think, that handles
this. It is similar to the nullable types provided elsewhere. Doubling
memory size simply for null-ness is silly and value types should never be
null anyway, that just isn't right. Anyway, as a whole, .NET can never
change the semantics of value types, but Nullable<T> should allow you to do
what you need to.
There are reasons for not allowing null(for example, there is no such thing
as a null number, although there are NaN's, NaT's, or whatever) and I
personally think its a valid concept. 2) For many of the same reasons as #1 (#1 is kind of a subset of #2),
why can't SQL Server and .NET have uniform types. This is really
pushing it now (I know) and probably will not happen anytime soon
(although Yukon may make steps towards this). I know this is a
drastic shift and would cause a lot of stuff to break, but it would be
the right thing to do and make code have less bugs accross the board.
For example, decimal, money, currency, DateTime, SmallTime, bit,
boolean and especially nulls (#1).
Nulls in a database are sometimes an evil thing, but they are nessecery.
That doesn't mean value types need them. I also don't know if it makes sense
to add money, currency, bit, SmallTime etc to the framework. 3) Automated creation of Solution Build Order built into Visual
Studio. The more I think about it, the more I'm convinced that this
would be a pretty easy "Add-On" to write. Microsoft refused to do this
and would have made many peoples lives a whole lot easier I think. In
short what this would mean is that you should be able to add 15
projects to a solution and then click on a button and it figures out
your build order depending on the references of each project. Visual
Studio includes a Solution Build Order but the problem is that you
have to set this list manually. And whenever there is a change (such
as adding a new project or a reference inside a project changing), you
have to update this list accordingly. The same even hold's true for
reference paths inside of a single project if you have (this only
becomes an issue if you need to have multiple reference paths inside
that project). I do see the need to allow the user to manually do it
also, but this would be a huge addition I think.
I don't understand your problem here. I have not had any real issue with
build orders, VS generally organizes it quite nicely based on dependences. 4) All arrays should start at 1! This is something (to me) that is
legacy and won't go away (probably ever). There really is no need for
zero based arrays. We are in high level languages now, so we should
be dealing with logic! I think the reason so many people stick to the
notion of zero based arrays is that it makes them feel like part of
the "c++" crowd and not part of the "VB" crowd, where many people
think c++ requires more skills. (I really do think this is the biggest
reason). Anyway, my thougths on this have nothing to do with any
particular language. I'm skilled in c#, VB.NET, VB 6.0 and C++ 6.0 so
I'm not biased at all. I mean, let's face it: If an array has 3 items
in it, then the Count = 3 and you can reference the last item like
this array[array.Count] which is completely logical to me.
Heh, I still think that argument is BS, the value you pass to an array is an
*offset* not a label of its sequential position. When I pass an array 0 it
means I want the item at offset 0, not that I want Item *number* 0. There is
a significant difference in slot counting and offsets. However, this too can
never change, its set in stone for the remaning life of .NET.
Dave

Nov 15 '05 #3
> 4) All arrays should start at 1!

Most of the time I have to go through all the array's items,
so I prefer to write

for (int i=0;i<Array.Length;i++)

then

for (int i=1;i<=Array.Length;i++)

or

for (int i=1;i<Array.Length+1;i++)

... I mean, let's face it: If an array has 3 items
in it, then the Count = 3 and you can reference the last item like
this array[array.Count] which is completely logical to me.


How often do you need to refer the last item of an array?
Nov 15 '05 #4
> 4) All arrays should start at 1! This is something (to me) that is
legacy and won't go away (probably ever). There really is no need for
zero based arrays. We are in high level languages now, so we should
be dealing with logic! I think the reason so many people stick to the
notion of zero based arrays is that it makes them feel like part of
the "c++" crowd and not part of the "VB" crowd, where many people
think c++ requires more skills. (I really do think this is the biggest
reason). Anyway, my thougths on this have nothing to do with any
particular language. I'm skilled in c#, VB.NET, VB 6.0 and C++ 6.0 so
I'm not biased at all. I mean, let's face it: If an array has 3 items
in it, then the Count = 3 and you can reference the last item like
this array[array.Count] which is completely logical to me.


I heard a couple years ago, that VB is language made by non-programmers
for programmers. Do not offend. But you should be pleased, that
you can choose between languages. And you should not
demand such a change becasue 0 based array are very useful.
Consider modulo(%).

Gawel
Nov 15 '05 #5
zero based arrays are useful? Why?

You can use the .Count property of the Array and you can also test for NULL.

Off by one is a very common bug and we have yet to fix the cause, The fault
is inherent in the design of C#.

"Gawelek" <ga*****@NOSPAMEKpoczta.gazeta.pl> wrote in message
news:eb**************@TK2MSFTNGP10.phx.gbl...
4) All arrays should start at 1! This is something (to me) that is
legacy and won't go away (probably ever). There really is no need for
zero based arrays. We are in high level languages now, so we should
be dealing with logic! I think the reason so many people stick to the
notion of zero based arrays is that it makes them feel like part of
the "c++" crowd and not part of the "VB" crowd, where many people
think c++ requires more skills. (I really do think this is the biggest
reason). Anyway, my thougths on this have nothing to do with any
particular language. I'm skilled in c#, VB.NET, VB 6.0 and C++ 6.0 so
I'm not biased at all. I mean, let's face it: If an array has 3 items
in it, then the Count = 3 and you can reference the last item like
this array[array.Count] which is completely logical to me.


I heard a couple years ago, that VB is language made by non-programmers
for programmers. Do not offend. But you should be pleased, that
you can choose between languages. And you should not
demand such a change becasue 0 based array are very useful.
Consider modulo(%).

Gawel

Nov 15 '05 #6
<<.>> wrote:
zero based arrays are useful? Why?

You can use the .Count property of the Array and you can also test for NULL.
I'm not sure what the relevance of your comments about Count and null
testing is...
Off by one is a very common bug and we have yet to fix the cause, The fault
is inherent in the design of C#.


I can't remember the last time I encountered an off-by-one bug due to
arrays being 0-based - although I'm sure that if they suddenly became
1-based instead, it would *then* be a common bug for me.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 15 '05 #7
Yes because you are so perfect.

Everybody does the Count-1 check every time after sitting hours in front of
a computer.

Its not representitive of the REAL WORLD starting at zero indexing which is
what we are providing solutions for.

Off by one never happens, thats why its even got a name.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
<<.>> wrote:
zero based arrays are useful? Why?

You can use the .Count property of the Array and you can also test for NULL.

I'm not sure what the relevance of your comments about Count and null
testing is...
Off by one is a very common bug and we have yet to fix the cause, The

fault is inherent in the design of C#.


I can't remember the last time I encountered an off-by-one bug due to
arrays being 0-based - although I'm sure that if they suddenly became
1-based instead, it would *then* be a common bug for me.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 15 '05 #8
<<.>> wrote:
Yes because you are so perfect.
No, because I'm used to it one particular way - as I believe many users
of C# are. (All of those with a C/C++/Java background, for starters.)
VB users happen to be used to it a different way.
Everybody does the Count-1 check every time after sitting hours in front of
a computer.
Well, I can't remember the last time I had an off by one error caused
by array indexing starting at zero. (Various other types of off by one
error, yes, but not to do with array indexing.)
Its not representitive of the REAL WORLD starting at zero indexing which is
what we are providing solutions for.
Well I for one am perfectly happy providing solutions using zero-based
arrays. From the other replies, it seems I'm not the only one either.
As a mathematician and a computer scientists, I'm just as happy
counting from 0 as from 1 - and mathematical concepts typically *do*
start with 0 rather than 1. Whether you count mathematical research and
modelling as the real world or not is up to you, but it's the real
world as far as an awful lot of people are concerned.
Off by one never happens, thats why its even got a name.


Did I suggest that it never happens? No. I suggested that I find it's
pretty rare - and that it would be made worse, not better, by changing
to a base 1 system - for me.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 15 '05 #9
People accept it because its legacy and are afraid of change, its like this
to win over the C/C++ developers.

Its not representitive of the real world scenario.

The first item is just that , FIRST item (NUMBER 1), not number 0.

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
<<.>> wrote:
Yes because you are so perfect.


No, because I'm used to it one particular way - as I believe many users
of C# are. (All of those with a C/C++/Java background, for starters.)
VB users happen to be used to it a different way.
Everybody does the Count-1 check every time after sitting hours in front of a computer.


Well, I can't remember the last time I had an off by one error caused
by array indexing starting at zero. (Various other types of off by one
error, yes, but not to do with array indexing.)
Its not representitive of the REAL WORLD starting at zero indexing which is what we are providing solutions for.


Well I for one am perfectly happy providing solutions using zero-based
arrays. From the other replies, it seems I'm not the only one either.
As a mathematician and a computer scientists, I'm just as happy
counting from 0 as from 1 - and mathematical concepts typically *do*
start with 0 rather than 1. Whether you count mathematical research and
modelling as the real world or not is up to you, but it's the real
world as far as an awful lot of people are concerned.
Off by one never happens, thats why its even got a name.


Did I suggest that it never happens? No. I suggested that I find it's
pretty rare - and that it would be made worse, not better, by changing
to a base 1 system - for me.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 15 '05 #10
<<.>> wrote:
People accept it because its legacy and are afraid of change, its like this
to win over the C/C++ developers.

Its not representitive of the real world scenario.
It's not representative of *some* real world scenarios. It's
representative of other things which are being modelled in computing.
The first item is just that , FIRST item (NUMBER 1), not number 0.


Yes, for some kinds of mapping of number to item, that's true. It's not
true of all mappings, however - many are naturally from 0.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 15 '05 #11
A collection, I have a collection of holes in front of me, I want the first
item from that collection.

I INSTINCTIVELY pick the FIRST hole!

I dont see a ZEROth hole.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
<<.>> wrote:
People accept it because its legacy and are afraid of change, its like this to win over the C/C++ developers.

Its not representitive of the real world scenario.


It's not representative of *some* real world scenarios. It's
representative of other things which are being modelled in computing.
The first item is just that , FIRST item (NUMBER 1), not number 0.


Yes, for some kinds of mapping of number to item, that's true. It's not
true of all mappings, however - many are naturally from 0.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 15 '05 #12
<<.>> wrote:
A collection, I have a collection of holes in front of me, I want the first
item from that collection.

I INSTINCTIVELY pick the FIRST hole!

I dont see a ZEROth hole.


That doesn't disprove my point at all - it just confirms what I've said
about there being *some* (many, even) models where mapping naturally
starts from 1. It in no way contradicts what I said, which is that
there are other models where mapping starts from 0.

There are various other ways in which arrays beginning with 0 make more
sense. For instance, take a mapping from (x, y) to a value. It's easy
to use

value = map[x+y*rowSize];

That's natural for 0-based co-ordinates (which are normal in maths).
You'd have to add one for 1-based arrays. If you also want to use 1-
based co-ordinates (to avoid having two different bases) you'd then
need something horrible such as:

value = map[x+(y-1)*rowSize];

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 15 '05 #13
Yes and in my arrse its using -1 indexing.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
<<.>> wrote:
A collection, I have a collection of holes in front of me, I want the first item from that collection.

I INSTINCTIVELY pick the FIRST hole!

I dont see a ZEROth hole.


That doesn't disprove my point at all - it just confirms what I've said
about there being *some* (many, even) models where mapping naturally
starts from 1. It in no way contradicts what I said, which is that
there are other models where mapping starts from 0.

There are various other ways in which arrays beginning with 0 make more
sense. For instance, take a mapping from (x, y) to a value. It's easy
to use

value = map[x+y*rowSize];

That's natural for 0-based co-ordinates (which are normal in maths).
You'd have to add one for 1-based arrays. If you also want to use 1-
based co-ordinates (to avoid having two different bases) you'd then
need something horrible such as:

value = map[x+(y-1)*rowSize];

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 15 '05 #14
I heard internally they battled over zero or 1 base too for a while.
Personally, I remember back in VB when you had to choose when you created
the array (IIRC). I always got confused thinking which way to go. I like
the zero based because its always the same, and you can deal with it and
your remember the gotchas from last statement you did. It probably all goes
back to bit addressing where the first low bit is bit 0 (not sure) I have
gotten fond of things like "for(int i=0; i < array.length; i++)", but you
can get used to anything I guess - just stick with one way if possible.

--
William Stacey, MVP

<.> wrote in message news:u9**************@TK2MSFTNGP10.phx.gbl...
A collection, I have a collection of holes in front of me, I want the first item from that collection.

I INSTINCTIVELY pick the FIRST hole!

I dont see a ZEROth hole.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
<<.>> wrote:
People accept it because its legacy and are afraid of change, its like this to win over the C/C++ developers.

Its not representitive of the real world scenario.


It's not representative of *some* real world scenarios. It's
representative of other things which are being modelled in computing.
The first item is just that , FIRST item (NUMBER 1), not number 0.


Yes, for some kinds of mapping of number to item, that's true. It's not
true of all mappings, however - many are naturally from 0.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too


Nov 15 '05 #15
Youi like it because you are used to it. Legacy.
"William Stacey" <st***********@mvps.org> wrote in message
news:OT**************@TK2MSFTNGP10.phx.gbl...
I heard internally they battled over zero or 1 base too for a while.
Personally, I remember back in VB when you had to choose when you created
the array (IIRC). I always got confused thinking which way to go. I like
the zero based because its always the same, and you can deal with it and
your remember the gotchas from last statement you did. It probably all goes back to bit addressing where the first low bit is bit 0 (not sure) I have
gotten fond of things like "for(int i=0; i < array.length; i++)", but you
can get used to anything I guess - just stick with one way if possible.

--
William Stacey, MVP

<.> wrote in message news:u9**************@TK2MSFTNGP10.phx.gbl...
A collection, I have a collection of holes in front of me, I want the

first
item from that collection.

I INSTINCTIVELY pick the FIRST hole!

I dont see a ZEROth hole.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
<<.>> wrote:
> People accept it because its legacy and are afraid of change, its like
this
> to win over the C/C++ developers.
>
> Its not representitive of the real world scenario.

It's not representative of *some* real world scenarios. It's
representative of other things which are being modelled in computing.

> The first item is just that , FIRST item (NUMBER 1), not number 0.

Yes, for some kinds of mapping of number to item, that's true. It's

not true of all mappings, however - many are naturally from 0.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too



Nov 15 '05 #16
Not really. At first I thought 1 based, however I like zero now. Most, if
not all Win32 structures are zero based IIRC, and most/all low level stuff
and hw stuff is zero based. Besides, it does not really matter now does it?
We got what we got so make the best of it :-)

--
William Stacey, MVP

<.> wrote in message news:eC**************@TK2MSFTNGP10.phx.gbl...
Youi like it because you are used to it. Legacy.
"William Stacey" <st***********@mvps.org> wrote in message
news:OT**************@TK2MSFTNGP10.phx.gbl...
I heard internally they battled over zero or 1 base too for a while.
Personally, I remember back in VB when you had to choose when you created
the array (IIRC). I always got confused thinking which way to go. I like the zero based because its always the same, and you can deal with it and
your remember the gotchas from last statement you did. It probably all

goes
back to bit addressing where the first low bit is bit 0 (not sure) I have gotten fond of things like "for(int i=0; i < array.length; i++)", but you can get used to anything I guess - just stick with one way if possible.

--
William Stacey, MVP

<.> wrote in message news:u9**************@TK2MSFTNGP10.phx.gbl...
A collection, I have a collection of holes in front of me, I want the

first
item from that collection.

I INSTINCTIVELY pick the FIRST hole!

I dont see a ZEROth hole.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
> <<.>> wrote:
> > People accept it because its legacy and are afraid of change, its

like this
> > to win over the C/C++ developers.
> >
> > Its not representitive of the real world scenario.
>
> It's not representative of *some* real world scenarios. It's
> representative of other things which are being modelled in computing. >
> > The first item is just that , FIRST item (NUMBER 1), not number 0. >
> Yes, for some kinds of mapping of number to item, that's true. It's not > true of all mappings, however - many are naturally from 0.
>
> --
> Jon Skeet - <sk***@pobox.com>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too



Nov 15 '05 #17
And just maybe you don't like because you are not. Newbie.
<.> wrote in message news:eC**************@TK2MSFTNGP10.phx.gbl...
Youi like it because you are used to it. Legacy.
"William Stacey" <st***********@mvps.org> wrote in message
news:OT**************@TK2MSFTNGP10.phx.gbl...
I heard internally they battled over zero or 1 base too for a while.
Personally, I remember back in VB when you had to choose when you created
the array (IIRC). I always got confused thinking which way to go. I like the zero based because its always the same, and you can deal with it and
your remember the gotchas from last statement you did. It probably all

goes
back to bit addressing where the first low bit is bit 0 (not sure) I have gotten fond of things like "for(int i=0; i < array.length; i++)", but you can get used to anything I guess - just stick with one way if possible.

--
William Stacey, MVP

<.> wrote in message news:u9**************@TK2MSFTNGP10.phx.gbl...
A collection, I have a collection of holes in front of me, I want the

first
item from that collection.

I INSTINCTIVELY pick the FIRST hole!

I dont see a ZEROth hole.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
> <<.>> wrote:
> > People accept it because its legacy and are afraid of change, its

like this
> > to win over the C/C++ developers.
> >
> > Its not representitive of the real world scenario.
>
> It's not representative of *some* real world scenarios. It's
> representative of other things which are being modelled in computing. >
> > The first item is just that , FIRST item (NUMBER 1), not number 0. >
> Yes, for some kinds of mapping of number to item, that's true. It's not > true of all mappings, however - many are naturally from 0.
>
> --
> Jon Skeet - <sk***@pobox.com>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too



Nov 15 '05 #18
He called me a newbie :(( fuckin tardboy.
"gerry" <ge**@hotmail.com> wrote in message
news:ek**************@TK2MSFTNGP12.phx.gbl...
And just maybe you don't like because you are not. Newbie.
<.> wrote in message news:eC**************@TK2MSFTNGP10.phx.gbl...
Youi like it because you are used to it. Legacy.
"William Stacey" <st***********@mvps.org> wrote in message
news:OT**************@TK2MSFTNGP10.phx.gbl...
I heard internally they battled over zero or 1 base too for a while.
Personally, I remember back in VB when you had to choose when you created the array (IIRC). I always got confused thinking which way to go. I like the zero based because its always the same, and you can deal with it and your remember the gotchas from last statement you did. It probably all
goes
back to bit addressing where the first low bit is bit 0 (not sure) I have gotten fond of things like "for(int i=0; i < array.length; i++)", but you can get used to anything I guess - just stick with one way if
possible.
--
William Stacey, MVP

<.> wrote in message news:u9**************@TK2MSFTNGP10.phx.gbl...
> A collection, I have a collection of holes in front of me, I want the first
> item from that collection.
>
> I INSTINCTIVELY pick the FIRST hole!
>
> I dont see a ZEROth hole.
>
>
> "Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
> news:MP************************@msnews.microsoft.c om...
> > <<.>> wrote:
> > > People accept it because its legacy and are afraid of change,
its like
> this
> > > to win over the C/C++ developers.
> > >
> > > Its not representitive of the real world scenario.
> >
> > It's not representative of *some* real world scenarios. It's
> > representative of other things which are being modelled in computing. > >
> > > The first item is just that , FIRST item (NUMBER 1), not number 0. > >
> > Yes, for some kinds of mapping of number to item, that's true.

It's not
> > true of all mappings, however - many are naturally from 0.
> >
> > --
> > Jon Skeet - <sk***@pobox.com>
> > http://www.pobox.com/~skeet
> > If replying to the group, please do not mail me too
>
>



Nov 15 '05 #19
thanks for the confirmation.
<.> wrote in message news:ux*************@TK2MSFTNGP12.phx.gbl...
He called me a newbie :(( fuckin tardboy.
"gerry" <ge**@hotmail.com> wrote in message
news:ek**************@TK2MSFTNGP12.phx.gbl...
And just maybe you don't like because you are not. Newbie.
<.> wrote in message news:eC**************@TK2MSFTNGP10.phx.gbl...
Youi like it because you are used to it. Legacy.
"William Stacey" <st***********@mvps.org> wrote in message
news:OT**************@TK2MSFTNGP10.phx.gbl...
> I heard internally they battled over zero or 1 base too for a while.
> Personally, I remember back in VB when you had to choose when you

created
> the array (IIRC). I always got confused thinking which way to go.
I
like
> the zero based because its always the same, and you can deal with it and > your remember the gotchas from last statement you did. It probably all goes
> back to bit addressing where the first low bit is bit 0 (not sure)
I have
> gotten fond of things like "for(int i=0; i < array.length; i++)",
but you
> can get used to anything I guess - just stick with one way if possible. >
> --
> William Stacey, MVP
>
> <.> wrote in message news:u9**************@TK2MSFTNGP10.phx.gbl...
> > A collection, I have a collection of holes in front of me, I want the > first
> > item from that collection.
> >
> > I INSTINCTIVELY pick the FIRST hole!
> >
> > I dont see a ZEROth hole.
> >
> >
> > "Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
> > news:MP************************@msnews.microsoft.c om...
> > > <<.>> wrote:
> > > > People accept it because its legacy and are afraid of change, its like
> > this
> > > > to win over the C/C++ developers.
> > > >
> > > > Its not representitive of the real world scenario.
> > >
> > > It's not representative of *some* real world scenarios. It's
> > > representative of other things which are being modelled in

computing.
> > >
> > > > The first item is just that , FIRST item (NUMBER 1), not
number 0.
> > >
> > > Yes, for some kinds of mapping of number to item, that's true.

It's not
> > > true of all mappings, however - many are naturally from 0.
> > >
> > > --
> > > Jon Skeet - <sk***@pobox.com>
> > > http://www.pobox.com/~skeet
> > > If replying to the group, please do not mail me too
> >
> >
>
>



Nov 15 '05 #20
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?
Nov 15 '05 #21
<.> wrote in message news:eC**************@TK2MSFTNGP10.phx.gbl...
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
Nov 15 '05 #22
Good point Daniel. And thanks for the vb6 sample. I remember that now and
shuttered a bit. :-)
If .NET programmers have an expectation, based on
prior experience, about what "base" arrays should be, .NET meets that
expectation.

Nov 15 '05 #23
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

On Thu, 22 Jan 2004 21:55:15 +0100, <.> wrote:
Youi like it because you are used to it. Legacy.
"William Stacey" <st***********@mvps.org> wrote in message
news:OT**************@TK2MSFTNGP10.phx.gbl...
I heard internally they battled over zero or 1 base too for a while.
Personally, I remember back in VB when you had to choose when you created
the array (IIRC). I always got confused thinking which way to go. I like
the zero based because its always the same, and you can deal with it and
your remember the gotchas from last statement you did. It probably all

goes
back to bit addressing where the first low bit is bit 0 (not sure) I have
gotten fond of things like "for(int i=0; i < array.length; i++)", but you
can get used to anything I guess - just stick with one way if possible.

--
William Stacey, MVP

Nov 15 '05 #24
Austin Ehlers <th***********************@hotmail.com> wrote:
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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 15 '05 #25
Yes it is you zero based array zealot!!
"Daniel Pratt" <ko******************@hotmail.com> wrote in message
news:#h**************@TK2MSFTNGP12.phx.gbl...
<.> wrote in message news:eC**************@TK2MSFTNGP10.phx.gbl...
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

Nov 15 '05 #26
On Thu, 22 Jan 2004 23:00:14 -0000, Jon Skeet [C# MVP]
<sk***@pobox.com> wrote:
Austin Ehlers <th***********************@hotmail.com> wrote:
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.

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.
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.


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
Nov 15 '05 #27
<<.>> wrote:
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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 15 '05 #28
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
Nov 15 '05 #29
malcolm <ch********@yahoo.com> wrote:
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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 15 '05 #30
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[i], array[II], ... , array[VII], ... , array[DCCLIIX], ... ,
array[MID], .. , array[MMIV]

Isn't it very beautiful?
Nov 15 '05 #31
funy :D

Notice how youre idea starts at I (one:D)

"Zürcher See" <aq****@cannabismail.com> wrote in message
news:O6**************@tk2msftngp13.phx.gbl...
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[i], array[II], ... , array[VII], ... , array[DCCLIIX], ... ,
array[MID], .. , array[MMIV]

Isn't it very beautiful?

Nov 15 '05 #32
<di********@discussion.microsoft.com> wrote:
Notice how youre idea starts at I (one:D)


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...)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 15 '05 #33
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
Nov 15 '05 #34
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...
Nov 15 '05 #35
malcolm <ch********@yahoo.com> wrote:
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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 15 '05 #36
Hi malcom,

"malcolm" <ch********@yahoo.com> wrote in message
news:4f**************************@posting.google.c om...
<snip>
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
Nov 15 '05 #37
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.
"malcolm" <ch********@yahoo.com> wrote in message
news:4f**************************@posting.google.c om...
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...

Nov 15 '05 #38
the first coordinate as you are so fond of, is the FIRST coordinate,
regardless of its value.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
malcolm <ch********@yahoo.com> wrote:
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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 15 '05 #39
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.

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
malcolm <ch********@yahoo.com> wrote:
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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 15 '05 #40
You can still set youre fantasy coordinate in the first position if you want
to refer to it as an ITEM in a collection, if not you can say hey my first
coordinate is (X,y) from the ORIGIN, its still the first bloomin coordinate.

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
malcolm <ch********@yahoo.com> wrote:
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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 15 '05 #41
<<.>> wrote:
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.


Do you really think you don't have to care what the lowest value of a
byte is?

My point is that a lot of things in life are 0-based. Lists may not be,
but not everything in life is a list, and a lot of computer science is
based on maths which is more naturally 0-based - so choosing a 0-based
system for the whole of computing was not a mistake, IMO.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 15 '05 #42
Cor
Hi Jon,

I think you even type with your 0th finger

Not offend, I just had fun.

Cor
Nov 15 '05 #43
Sure that can stay that way for interop, but at the high level, let the
compiler take care of it, thats why we invent tools, so save us ths hassle.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
<<.>> wrote:
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.


Do you really think you don't have to care what the lowest value of a
byte is?

My point is that a lot of things in life are 0-based. Lists may not be,
but not everything in life is a list, and a lot of computer science is
based on maths which is more naturally 0-based - so choosing a 0-based
system for the whole of computing was not a mistake, IMO.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 15 '05 #44
<<.>> wrote:
Sure that can stay that way for interop, but at the high level, let the
compiler take care of it, thats why we invent tools, so save us ths hassle.


.... and add hassle for people who are still writing things to do with
computer science (or anything else which is naturally 0-based).

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 15 '05 #45
Hello Jon, you said very interesting points, my thoughts below:

Jon Skeet [C# MVP] <sk***@pobox.com> wrote in message news:<MP************************@msnews.microsoft. com>...
malcolm <ch********@yahoo.com> wrote:
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.

good points, you're probably right on this case.
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.) Yes, this would be foolish (although SQL Server does exactly that for
all thier data types). If I had to really implement this I would
implement some sort of low level mapping hash table (probably on the
heap and stack for ref and val types). Didn't give it much thought on
the implementation.
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). As someone from a strong mathematical background, I would honestly say
this argument doesn't hold. For example, simplify the Cartesian
coordinate system by only having an x-axis. In your example, x=0
signifies the starting point. Well this intuitively describes an array
with "Nothing" in it. When x=1, then it abstracty describes an array
with "one" element, etc., etc. In your example, an array with one
element starts at x=0, well where does an array with nothing in it
lie? At x=-1? Please do tell.
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.


This statement you made shows me that the seeds of this "zero-based"
propoganda have far reaching effects in your psyche. All mankind (that
I know of) uses numbers to count things (and of course other things,
such as math, etc.). The number "one" represents for example one
apple. The number "two" represents for example two stamps. You
basically just told me that humankind got it wrong and zero should
represent "one apple".

Here's where I find your statement very intersting though. I would
argue that mankind could have chosen either counting system. We could
have chosen to start with 1 or zero or probably even 12! Whats
important is the consistancy of the mathematics and the formulas that
have been so carefully constructed over the past 2000 years. For the
same reason that there is no natural base radix point in mathimatics.
Base 10 is really a human convienience. Anyway, my point is that it's
arbitrary and that decision has already been made. My original post
wasn't argueing that humans got the number wrong in math and science
(as there is no philosophical correct way) it was that humans got the
number wrong in computers. If humans chose to start at 12, then I
would argue that computers should start at 12 (not 11).

-Dave
Nov 15 '05 #46
malcolm <ch********@yahoo.com> wrote:
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.)
Yes, this would be foolish (although SQL Server does exactly that for
all thier data types). If I had to really implement this I would
implement some sort of low level mapping hash table (probably on the
heap and stack for ref and val types). Didn't give it much thought on
the implementation.
But issues which come up in lowest-level implementations repeat
themselves. For instance, say you're trying to display a grid of
elements. The rectangle for element (x, y) is
(x*boxWidth, y*boxHeight) + (origin) in a 0-based system. If everything
is 1-based, you need:

((x-1)*boxWidth+1, (y-1)*boxHeight+1) + (origin) - and what is the
natural origin in a 1-based system?

That kind of issue (its general "shape") will come up at all levels -
from memory organisation, to drawing, to paging through data. Why allow
only those dealing at the lowest level to benefit from this
mathematical property?
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).

As someone from a strong mathematical background, I would honestly say
this argument doesn't hold. For example, simplify the Cartesian
coordinate system by only having an x-axis. In your example, x=0
signifies the starting point. Well this intuitively describes an array
with "Nothing" in it. When x=1, then it abstracty describes an array
with "one" element, etc., etc. In your example, an array with one
element starts at x=0, well where does an array with nothing in it
lie? At x=-1? Please do tell.


Any array has a range of [0, length). If the length is 0, that means
the range is [0,0) - which is an empty range.

A good real world example of this is a tape measure. Where is the first
centimetre on a tape measure? It starts at 0 and finishes on but not
including the line for 1. A tape measure starting at 1 would be very
odd, surely - you'd have to subtract one from the end of whatever you
were measuring in order to get the actual length! This is what I mean
by 0 being a more natural starting point than 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.


This statement you made shows me that the seeds of this "zero-based"
propoganda have far reaching effects in your psyche. All mankind (that
I know of) uses numbers to count things (and of course other things,
such as math, etc.). The number "one" represents for example one
apple. The number "two" represents for example two stamps. You
basically just told me that humankind got it wrong and zero should
represent "one apple".


Nope. I'm saying that if we started counting at zero rather than one,
starting with "no apples" before "one apple" then things would be more
consistent - and surely "no apples" is a more reasonable base state
anyway, isn't it? If you don't start with zero, what happens when you
take away the one and only apple?
Here's where I find your statement very intersting though. I would
argue that mankind could have chosen either counting system. We could
have chosen to start with 1 or zero or probably even 12! Whats
important is the consistancy of the mathematics and the formulas that
have been so carefully constructed over the past 2000 years. For the
same reason that there is no natural base radix point in mathimatics.
That kind of base is an entirely different matter. While a number
itself is the same in all bases, that doesn't mean that *starting*
counting at any point is equivalent. 0 has special properties which no
other numbers have, whatever base you express them in.
Base 10 is really a human convienience. Anyway, my point is that it's
arbitrary and that decision has already been made. My original post
wasn't argueing that humans got the number wrong in math and science
(as there is no philosophical correct way) it was that humans got the
number wrong in computers. If humans chose to start at 12, then I
would argue that computers should start at 12 (not 11).


Computers should start at 0 for the reasons I've given before - it's
not arbitrary, 0 has unique properties. It doesn't depend, IMO, on
where humans start counting - although to start counting at anything
other than 0 or 1 would be *very* strange. Again, this isn't the same
as what base a number is expressed in.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 15 '05 #47
> 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.


Indeed. Neither system is better overall. It's like asking which is the
best day to consider as the start of the week. Is it when you start work,
or start to play, the Sabbath, after the Sabbath, whose Sabbath? It's
mostly a matter of what you are used to or what suits your circumstances.

In Pascal you can set the range yourself when you declare the array,
so it can start at 0, 1, -123, or Blue (assuming Blue is a member of
an integral type). Now everyone is happy!

Better still, access array elements through iterators, which is much
nicer than the abstraction of an array index:

// Sorry I don't know much C#.
std::vector<TMyClass> MyVec;
..
..
..
for (std::vector<TMyClass>::iterator I = MyVec.begin();
I != MyVec.end(); ++I)
{
I->SomeMethod();
}

Personally I have a C/C++ background and prefer 0-based arrays.
Arnold the Aardvark
Nov 15 '05 #48
Thats how they SHOULD have done it on C# in my view, make the start user
definable then its flexible for everybody how they want to represent theyre
data.

With this method they can still implement this change in later versions
while at the same time not breaking earlier versions, we can but hope to
have userdefinable start boundries of arrays.
"Arnold the Aardvark" <aa******@REMOVE.tubulidentata.demon.co.uk> wrote in
message news:bu*******************@news.demon.co.uk...
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.


Indeed. Neither system is better overall. It's like asking which is the
best day to consider as the start of the week. Is it when you start work,
or start to play, the Sabbath, after the Sabbath, whose Sabbath? It's
mostly a matter of what you are used to or what suits your circumstances.

In Pascal you can set the range yourself when you declare the array,
so it can start at 0, 1, -123, or Blue (assuming Blue is a member of
an integral type). Now everyone is happy!

Better still, access array elements through iterators, which is much
nicer than the abstraction of an array index:

// Sorry I don't know much C#.
std::vector<TMyClass> MyVec;
.
.
.
for (std::vector<TMyClass>::iterator I = MyVec.begin();
I != MyVec.end(); ++I)
{
I->SomeMethod();
}

Personally I have a C/C++ background and prefer 0-based arrays.
Arnold the Aardvark

Nov 15 '05 #49
<<.>> wrote:
Thats how they SHOULD have done it on C# in my view, make the start user
definable then its flexible for everybody how they want to represent theyre
data.
However, if there's no "normal" convention used for all non-specialist
uses, you need to consult the documentation carefully every time a 3rd
party library takes or returns an array, just to find out its base. No
thanks.
With this method they can still implement this change in later versions
while at the same time not breaking earlier versions, we can but hope to
have userdefinable start boundries of arrays.


You already can, if you're prepared to use the .NET Array type rather
than just C# arrays which are more restrictive. If you cast the Array
to IList, you can even use an indexer on it to make it look like normal
array access.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 15 '05 #50

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

5
by: Lorenzo Braidi | last post by:
Hallo everyone, is there someone who is partecipating to the Microsoft Yukon Beta test and who can send me some picture of the new GUI of Enterprise Manager and Query Analyser? Send it at my...
1
by: Jack Victor | last post by:
Hi, Can anyone please tell me if there will be support in SQL2005 - Yukon for datafiles to be placed on Compressed volumes or if there will be compression of the data that is transparent to the...
0
by: Roberto Barrantes | last post by:
I installed Yukon Beta 2 in a computer with windows server 2003 when I tried to create a Data Transformation Project I got the following error: Failed to open package file "C:\Documents and...
6
by: James Liu | last post by:
I did some search and didn't find anything about whether Yokon will support sequence object. Appreciate it if you can reply with some resources. Thanks, James
15
by: nospam | last post by:
Once Yukon is released (whenever that might be) does anyone from MS have any comment on licensing for Yukon and on SQL 2000. I really don't think anyone with SQL 2000 licenses are going to...
83
by: newby2c | last post by:
My personal K&R (3rd edition) wish list: 1. That a 3rd edition is actually published! 2. Make any and all corrections from earlier editions. 3. Update to comply with the c99 Standard. 4. A...
1
by: Marco | last post by:
Is there a wishlist for c# (or .Net) where we could suggest changes or improvements ? Mine is to have access to SmallChange property of Panel scrollbars as well as access to theirs Scroll event....
5
by: | last post by:
I love the .NET framwework. Compared to mfc this is a dream to work with. I would love if the C# and maybe other languages too, somehow gives more friendly messages when executed on a machine...
1
by: Olaf Baeyens | last post by:
Something for the C#/JIT wishlist. I am looking at the generated IL Assembler code and the generated real x86 code and I am facinated about the quality of the generated code. It comes to near...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
0
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.