2 added 1 character in body
source | link

You give the answer yourself in the third bullet point, and you dismiss it too easily.

Let me delve into my personal experience from when I learned C in the mid-1980s. I remember when for the first I time saw 68k assembler code produced from indexing an array in C and realized that variables are just constant addresses, and indices are just offsets to them, so that addressing an array element a[i] could be understood as *(a+i) which simply was a readily available adressing mode in machine code if address a was already in a register.

It was a revelation on many levels: What C is (a macro assembler with a few bells and whistles plus standard library), what a compiler does, under what constraints programming languages work, and why C was so fast.

Why do you want to deprive your students of this insight? I think teaching arrays (or any programming, really) benefits tremendously from teaching memory addresses and some rudimentary assembler, so just go for it. All language abstraction is operating under the constraints of the metal. Your students will never understand why certain seemingly simple things are expensive or impossible if they don't know what they are actually doing.1

To sum up, essentially your third bullet point is the reason for the decision by the designers of C (or probably rather, BCPL or B) to start indexing at 0. Saving a subtraction at each element access, i.e. in allmany hot loops, was certainly highly relvant in 1970. True, today these original reasons are largely irrelevant; but today we have 45 years of code and a diverse C-rooted language tree. WithRegarding these languages we are locked in for good. As Jörg correctly mentioned in another answer, the decision was made differently for many other languages, probably not coincidentally some for which speed is secondary and some who target a lay audience.


1Don't get me wrong, I like abstraction. Having had the glimpse under the hood lets me actually appreciate the saftey, correctness and comfort provided by high-level languages and libraries.

You give the answer yourself in the third bullet point, and you dismiss it too easily.

Let me delve into my personal experience from when I learned C in the mid-1980s. I remember when for the first I time saw 68k assembler code produced from indexing an array in C and realized that variables are just constant addresses, and indices are just offsets to them, so that addressing an array element a[i] could be understood as *(a+i) which simply was a readily available adressing mode in machine code if address a was already in a register.

It was a revelation on many levels: What C is (a macro assembler with a few bells and whistles plus standard library), what a compiler does, under what constraints programming languages work, and why C was so fast.

Why do you want to deprive your students of this insight? I think teaching arrays (or any programming, really) benefits tremendously from teaching memory addresses and some rudimentary assembler, so just go for it. All language abstraction is operating under the constraints of the metal. Your students will never understand why certain seemingly simple things are expensive or impossible if they don't know what they are actually doing.1

To sum up, essentially your third bullet point is the reason for the decision by the designers of C (or probably rather, BCPL or B) to start indexing at 0. Saving a subtraction at each element access, i.e. in all hot loops, was certainly highly relvant in 1970. True, today these original reasons are largely irrelevant; but today we have 45 years of code and a diverse C-rooted language tree. With these languages we are locked in for good. As Jörg correctly mentioned in another answer, the decision was made differently for many other languages, probably not coincidentally some for which speed is secondary and some who target a lay audience.


1Don't get me wrong, I like abstraction. Having had the glimpse under the hood lets me actually appreciate the saftey, correctness and comfort provided by high-level languages and libraries.

You give the answer yourself in the third bullet point, and you dismiss it too easily.

Let me delve into my personal experience from when I learned C in the mid-1980s. I remember when for the first I time saw 68k assembler code produced from indexing an array in C and realized that variables are just constant addresses, and indices are just offsets to them, so that addressing an array element a[i] could be understood as *(a+i) which simply was a readily available adressing mode in machine code if address a was already in a register.

It was a revelation on many levels: What C is (a macro assembler with a few bells and whistles plus standard library), what a compiler does, under what constraints programming languages work, and why C was so fast.

Why do you want to deprive your students of this insight? I think teaching arrays (or any programming, really) benefits tremendously from teaching memory addresses and some rudimentary assembler, so just go for it. All language abstraction is operating under the constraints of the metal. Your students will never understand why certain seemingly simple things are expensive or impossible if they don't know what they are actually doing.1

To sum up, essentially your third bullet point is the reason for the decision by the designers of C (or probably rather, BCPL or B) to start indexing at 0. Saving a subtraction at each element access, i.e. in many hot loops, was certainly highly relvant in 1970. True, today these original reasons are largely irrelevant; but today we have 45 years of code and a diverse C-rooted language tree. Regarding these languages we are locked in for good. As Jörg correctly mentioned in another answer, the decision was made differently for many other languages, probably not coincidentally some for which speed is secondary and some who target a lay audience.


1Don't get me wrong, I like abstraction. Having had the glimpse under the hood lets me actually appreciate the saftey, correctness and comfort provided by high-level languages and libraries.

1
source | link

You give the answer yourself in the third bullet point, and you dismiss it too easily.

Let me delve into my personal experience from when I learned C in the mid-1980s. I remember when for the first I time saw 68k assembler code produced from indexing an array in C and realized that variables are just constant addresses, and indices are just offsets to them, so that addressing an array element a[i] could be understood as *(a+i) which simply was a readily available adressing mode in machine code if address a was already in a register.

It was a revelation on many levels: What C is (a macro assembler with a few bells and whistles plus standard library), what a compiler does, under what constraints programming languages work, and why C was so fast.

Why do you want to deprive your students of this insight? I think teaching arrays (or any programming, really) benefits tremendously from teaching memory addresses and some rudimentary assembler, so just go for it. All language abstraction is operating under the constraints of the metal. Your students will never understand why certain seemingly simple things are expensive or impossible if they don't know what they are actually doing.1

To sum up, essentially your third bullet point is the reason for the decision by the designers of C (or probably rather, BCPL or B) to start indexing at 0. Saving a subtraction at each element access, i.e. in all hot loops, was certainly highly relvant in 1970. True, today these original reasons are largely irrelevant; but today we have 45 years of code and a diverse C-rooted language tree. With these languages we are locked in for good. As Jörg correctly mentioned in another answer, the decision was made differently for many other languages, probably not coincidentally some for which speed is secondary and some who target a lay audience.


1Don't get me wrong, I like abstraction. Having had the glimpse under the hood lets me actually appreciate the saftey, correctness and comfort provided by high-level languages and libraries.