Zero based indexing gone too far
-
@bstorer said:
PEOPLE DON'T START COUNTING AT ZERO!
Of course we start at zero. Let's say I go and count the number of characters in an arbitrary string, and that string has zero characters? What is my count? Zero! It is only because we are expecting to find something when we count that we falsely assume that we start counting at one.
Personally, I am used to either method, and I only have a preference for 0-based indicies because of my math background. Mathematicians often name a variable representing the first item as "t-naught" or "x-naught". I also think that this is where the practice came about in programming.
P.S. - I just mentioned this discussion to my wife, and she exclaimed "You people argue about the stupidest things!" How true...
-
@Helios said:
How is it not relevant to the discussion? We're talking about 0-based indexes versus 1-based ones and I pointed out how 1-based indexing creates confusion. While this confusion has little repercussions in everyday life, in programming, off by 1 errors can be disastrous. Now, how is that irrelevant?
The discussion was about how to conceptualize containers of data; whether by 'index' (start point, length) or by 'data position' (and identifier for discreet container slots).
Throwing into the mix how people started counting at one in the calendar system and thereby only having 1999 years pass when we celebrate 2000 years on the calendar is a historical footnote with little to add to a discussion on which method of conceptualization is better suited in general for programming.*
*or even if one method is truly better or if both methods just have different uses
-
@BeenThere said:
@tster said:
TRWTF is that you say that.
No different than saying the 1800s consisted of the 19th century.
No. Because I've heard people say "the 1800s", "the 19th century", and "happy 30th birthday." But never in my life have I heard someone say "have a great 31st year."
-
@tster said:
No. Because I've heard people say "the 1800s", "the 19th century", and "happy 30th birthday." But never in my life have I heard someone say "have a great 31st year."
Have a great 1021st post.
-
@MasterPlanSoftware said:
So you normally start counting at '0' and not '1'?
We all do. It's just that nobody bothers to actually count it out when one has nothing.
-
@Nandurius said:
@Kazan said:
yes because let's do one additional subtract-immediate operation every time we do an array index... it won't add up to billions of instructions or anything
Why would you have to execute an add instruction? If it's defined to work this way in the language, the compiler can take care of this. For example, you can store the memory address minus one for array references.
You don't really want to move away from 0-based indexes, as that's what is commonly used in mathematics. Unfortunately the one program that tried to 'simplify' indexing is Matlab, which starts indexes at 1, which makes entering (0-based) formulas needlessly confusing.
You have a point about storing a pre-offested memory addresses for the base address.. however it has the problem of making your array pointers and normal pointers no longer equivalent and forgetting this and using an array pointer as a normal pointer (something i do often - especially when saving/loading binary blobls of data that don't require representation transformations) can lead to crashes, etc
-
I meant to post this yesterday, but forgot. 8=[
@bstorer said:
@NorseLaQuet said:
Most languages (except VB and a few other POS
Cute piece of trolling here. Also, VB lets you
languages) use 0 indexing.
pick between 1 or 0.Since version 7 (.NET), it doesn't. The only option is 0.
-
Why the hell do you think this wouldn't work if arrays were 1-indexed? What effect would that have on anything?
When -1 is the last element you can seamlessly iterate from the 1st to last element and vice-versa, it would obvisouly get f-up'd if there was no 0 index.
for (i = -1; condition; i++) {
// When i = 0 you're f'd.
element = array[i];
}
Plus any operation like array[i + n] would have un-expected results at 0.
0-based indexes just plain make more sense and seem more natural to me.
-
@MasterPlanSoftware said:
@NorseLaQuet said:
Please give meone good reasen why 1-indexing is a good idea.
Because that is how people think and therefore it is more natural?
Ah, MPS... :-( I was with you until here.
Who cares what [b]people[/b] think? They're mere mortals, and shouldn't be able to understand what we developers can. That's one of the things that makes us better than them, you know.
-
The truly insane do it both ways. e.g., APL allows you to programatically choose whether your "index origin" (as it calls it) is zero or one.
Now, throw some "systems" programmers and some "application" programmers in a room, and guess what happens -- they argue which one is right, they do it both ways, and their source code is scarred forever from this idiotic war.
-
This argument is simply stupid and is getting worse by the post.
First off, we are not programming for people, we are programming for the computer. Loose track of that, and you are doomed for failure. High level languages are great for developing specific code that meet specific demands very quickly and effectively. But my PHP script runs on the same CPU, the same RAM and the same HD as my C++ code. Why should I not try and keep track of how my php scripts hit my CPU at the same level as my C++ programs? High level languages do not exist to abstract out functionality and reduce responsibility on part of the programmer - they exist to make developing specific software quicker. We should never loose sight of the effects our scripts have on our computers, because when you do that you are doomed to write code that consumes too much memory or wastes too much CPU power.
Often times high level programmers do not know about memory management, or writing optimized code. They may be great at deploying OOP patterns and writing extendable, solid software (and that's a big "may," considering some of the code we see in TDWTF), but if they do not understand the costs involved in dynamic memory allocations, or the costs of their memory footprint - their code will most likely be slower then shit.
Now that I have that off my chest, to continue the original argument; indexes are *not* abstractions of how computers work. They _are_ how computers work. Computers work via memory offsets, and a memory offset is exactly what an index is. Therefore, an index is not whatever fluffy little definition we make it out to be - it is a very important part of how computers operate. A 0 index is (0 * sizeof(<datatype>)) passed the first element, and the 1 index is (1 * sizeof(<datatype>)) passed the first element. Its as simple as that. You cant change that at a low level.Sure, you can write a scripting language that simply subtracts one from each index for you so you can use your 1 indicies. My question is: why? You might start counting at one, but you start measuring the distance between point A and point B at 0. Index = offset, offsets start at no distance, or 0. Why would you want that? So you can bring high level developers just one step further away form knowing how the computer runs their code? So you can make them feel more comfortable by allowing them one more thing to neglect when they design their systems? WTF is the point? This is a very silly argument, and I pray to God you 1-index supporters are not on the development board for the Php-7 standard becasue the day a language switches to 1-indexing is the day I stop using it.
I am not going to bend over backwards because I program in C++ and am used to dealing with how programs run just so some l33t high schooler can feel an ounce more comfortable writing his Hello World application.
-
@MasterPlanSoftware said:
Because that is how people think and therefore it is more natural?
Why should the language make sense to the computer and not to the person instead?
I wonder if it's really all that natural. When I first learned to count, I kept wanting to start at zero and adults kept "correcting" me. (Then I had to unlearn their way to program in C.) I've known other children to do the same thing.
-
somone is getting aa bit excercized about the indexes.
-
@tster said:
No. Because I've heard people say "the 1800s", "the 19th century", and "happy 30th birthday." But never in my life have I heard someone say "have a great 31st year."
Seems pretty common to me, but that's my experience.
Btw: All the fuckwits calling specific users "idiots, assholes, or retards" for not liking zero based indexes - grow the fuck up. No one is actually saying they don't "get" why zero is generally used, but are mentioning the fact that 1 base is actually more appropriate for certain situations, and that's a rational argument.I happen to like zero based indexes, but seeing people go off like in the last few posts is really a pathetic and sad sight - get a life already.
-
@BeenThere said:
Btw: All the fuckwits calling specific users "idiots, assholes, or retards" for not liking zero based indexes - grow the fuck up. No one is actually saying they don't "get" why zero is generally used, but are mentioning the fact that 1 base is actually more appropriate for certain situations, and that's a rational argument.I happen to like zero based indexes, but seeing people go off like in the last few posts is really a pathetic and sad sight - get a life already.
x 2
-
@NorseLaQuet said:
First off, we are not programming for people, we are programming for the computer.
I tend too see it exactly the other way. Eventually, we are programming for people. Computers do not pay us for our work, people do.
Now that I have that off my chest, to continue the original argument; indexes are *not* abstractions of how computers work. They _are_ how computers work. Computers work via memory offsets, and a memory offset is exactly what an index is. Therefore, an index is not whatever fluffy little definition we make it out to be - it is a very important part of how computers operate. A 0 index is (0 * sizeof(<datatype>)) passed the first element, and the 1 index is (1 * sizeof(<datatype>)) passed the first element. Its as simple as that. You cant change that at a low level.
This might be true for low-level languages like C, but for high-level languages, it doesn't hold. Just look at the way Luna handles arrays. And without the design decision "arrays=pointers", 1-based index comes with no actual cost. As soon as you go to languages like Java and C#, it turns out that 0-based index doesn't save anything at all. Because an array, like any other object, consists of much more than the actual data stored in it. It also contains type information, size information etc.
Anyway, for anything that is not system level programming, having the programmer worry about how the computer actually works is BAD. It's the compiler / interpreter / runtime to know those little details. In many cases, programs live by far much longer than the hardware they were originally written for, so any hand-crafted "optimization" for one platform might turn out counterproductive on the next one. Any clever way to save a few nanoseconds might make the program harder to read during maintenance, which is likely a cause of higher costs than all lost processor cycles together.
BTW, and now I'm wearing my "moderator" cap, flamewar is over.
-
Cambodia had a year zero, and look what happned there.
-
@ammoQ said:
Anyway, for anything that is not system level programming, having the programmer worry about how the computer actually works is BAD. It's the compiler / interpreter / runtime to know those little details. In many cases, programs live by far much longer than the hardware they were originally written for, so any hand-crafted "optimization" for one platform might turn out counterproductive on the next one. Any clever way to save a few nanoseconds might make the program harder to read during maintenance, which is likely a cause of higher costs than all lost processor cycles together.
You're right than in general a programmer can trust a modern compiler to do the optimizations and premature optimization is a bad thing. But even a high-level programming language developer has to know how computers work, there are concepts that are generally true for most platforms. Like CPU memory caching. When you loop through a 2 dimensional array you make sure that you go row-by-row and not column-by-column to maximize cache hits and minimize cache misses. That's something the compiler cannot do for you, apart from really trivial cases. Even if the architecture doesn't support memory caching, you won't lose anything, but you will lose loads of performance if you do it column-by-column on a caching CPU.
Basically my point is: A programmer has to know how computers work. Even if he only does Javascript.
-
@NorseLaQuet said:
First off, we are not programming for people, we are programming for the computer.
@Knuth said:
Let us change our traditional attitude to the construction of programs. Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.
As already pointed out by ammoQ, we are programming for other programmers, not for the hardware. Hardware is cheap, developer time is expensive and user time (ineffective UI, downtime due to bugs) is the most expensive.
@NorseLaQuet said:
High level languages do not exist to abstract out functionality and reduce responsibility on part of the programmer...
That is exactly why they exist. Garbage collection was invented to remove the burden of memory management from the programmer and put it on the computer which is much more effective at it than a human ever could be. Any abstraction is "leaky" meaning that low-level details may still crop up at the high-level, but the aim of a high-level developer should not be to code like a low-level developer merely to avoid these leaks. If extensive profiling shows a leak impacts performance, sure, but as has already been pointed out several times 1-based indexes would not affect performance at all.
@NorseLaQuet said:
Now that I have that off my chest, to continue the original argument; indexes are *not* abstractions of how computers work. They _are_ how computers work. Computers work via memory offsets, and a memory offset is exactly what an index is. Therefore, an index is not whatever fluffy little definition we make it out to be - it is a very important part of how computers operate. A 0 index is (0 * sizeof(<datatype>)) passed the first element, and the 1 index is (1 * sizeof(<datatype>)) passed the first element. Its as simple as that.
No it isn't. Indexes are an abstraction created by humans. Using memory offsets is the simplest way to create such a system at the hardware level. C is pretty much assembly so it inherited this same method for managing indexes. Higher-level languages don't even implement arrays as memory offsets, but instead as hashtables or linked-lists.
@NorseLaQuet said:
You might start counting at one, but you start measuring the distance between point A and point B at 0. Index = offset, offsets start at no distance, or 0.
Your inability to understand what is being said here is quite sad. Indexes are not offsets, that is merely one way of implementing them. It is the most sensible way at the hardware level, but is quite silly at the higher level.
-
@DrJokepu said:
Basically my point is: A programmer has to know how computers work. Even if he only does Javascript.
And my basic piont is that programmers shouldn't have to know how computers work. The reason they need to know is because of weak abstractions, like 0-based indexing. Actually, I take that back, 0-based indexing isn't even a weak abstraction in high-level languages since the index is not being translated directly into a memory offset in hardware. In high-level languages 0-based indexing is just an absurd legacy practice with no real necessity. I'm going to make a stab in the dark and say that fewer than 0.1% of programmers actually understand top-to-bottom how their software is working. This includes everything from the high-level syntax, the parser, the VM, the OS kernel, CPU instructions, microcode and logic circuits.
-
@morbiuswilters said:
@NorseLaQuet said:
First off, we are not programming for people, we are programming for the computer.
@Knuth said:
Let us change our traditional attitude to the construction of programs. Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.
As already pointed out by ammoQ, we are programming for other programmers, not for the hardware. Hardware is cheap, developer time is expensive and user time (ineffective UI, downtime due to bugs) is the most expensive.
Well, next time instead of writing a program, simply ask the computer what to do instead... I don't think you are getting what I am saying here, we have to conform to how computers understand things to get our programs to run. You are developing code that the computer will understand, and in order to do that you should always take into consideration what affects your code has on the computer's resources.
@NorseLaQuet said:
High level languages do not exist to abstract out functionality and reduce responsibility on part of the programmer...
That is exactly why they exist. Garbage collection was invented to remove the burden of memory management from the programmer and put it on the computer which is much more effective at it than a human ever could be. Any abstraction is "leaky" meaning that low-level details may still crop up at the high-level, but the aim of a high-level developer should not be to code like a low-level developer merely to avoid these leaks. If extensive profiling shows a leak impacts performance, sure, but as has already been pointed out several times 1-based indexes would not affect performance at all.
Wow. This is great. For all of you who don't want to sift though this paragraph; he just basically said: "High level programmers should not make their code resource aware, and should go about consuming as much resources as they want of the system as long as it maintains readability to other humans." If google thought like you, I doubt gmail and google reader would be such quick applications.
@NorseLaQuet said:
Now that I have that off my chest, to continue the original argument; indexes are *not* abstractions of how computers work. They _are_ how computers work. Computers work via memory offsets, and a memory offset is exactly what an index is. Therefore, an index is not whatever fluffy little definition we make it out to be - it is a very important part of how computers operate. A 0 index is (0 * sizeof(<datatype>)) passed the first element, and the 1 index is (1 * sizeof(<datatype>)) passed the first element. Its as simple as that.
No it isn't. Indexes are an abstraction created by humans. Using memory offsets is the simplest way to create such a system at the hardware level. C is pretty much assembly so it inherited this same method for managing indexes. Higher-level languages don't even implement arrays as memory offsets, but instead as hashtables or linked-lists.
I thought that high level developers should not worry about what data structure their VM decides to put their magical re-sizable arrays? So per your, argument if the VM decides to use a vector, your arrays should be 0-indexed and if the VM chooses a linked list it should be 1-indexed. That would be confusing. Why should there be a difference between how your index things just because one is native pointer arithmetic and the other is a more complex data structure?
And again, indexes are not abstractions. I think you are slightly daft here. All variables in the program are referred to by memory offsets. Every single one. An index is simply an offset multiplied by the size of the datatype passed the first element of the array.You should read the chapter about pointers in sams teach yourself C++ in 21 days again, and I think you might pick up on some new ideas for you.
@NorseLaQuet said:
You might start counting at one, but you start measuring the distance between point A and point B at 0. Index = offset, offsets start at no distance, or 0.
Your inability to understand what is being said here is quite sad. Indexes are not offsets, that is merely one way of implementing them. It is the most sensible way at the hardware level, but is quite silly at the higher level.
I still don't get it. Why would you want 1-indexed arrays? Why? Just because its 'more natuaral' to new developers? Like I said already, I have been programming for a hell of a long time, and most of my development has been with low level languages. It would be just plain stupid if high level language developers decided one day, in order to accommodate young programs, to make my life more difficult.
And my basic piont is that programmers shouldn't have to know how computers work. The reason they need to know is because of weak abstractions, like 0-based indexing. Actually, I take that back, 0-based indexing isn't even a weak abstraction in high-level languages since the index is not being translated directly into a memory offset in hardware. In high-level languages 0-based indexing is just an absurd legacy practice with no real necessity. I'm going to make a stab in the dark and say that fewer than 0.1% of programmers actually understand top-to-bottom how their software is working. This includes everything from the high-level syntax, the parser, the VM, the OS kernel, CPU instructions, microcode and logic circuits.
You, my friend, have just made my list of top 10 morons.
The reason they need to know is because they need to have respect for the effects code has on the host machine. Not to the individual components level, but everything from the syntax to how their code is ran by the processor. I think you have a very shitty attitude to say that only 0.1% programmers are as smart as you. Grow the fuck up, for the love of God.
-
@NorseLaQuet said:
The reason they need to know is because they need to have respect for the effects code has on the host machine. Not to the individual components level, but everything from the syntax to how their code is ran by the processor. I think you have a very shitty attitude to say that only 0.1% programmers are as smart as you. Grow the fuck up, for the love of God.
I doubt Morbius claims to understand all the shit he listed. I surely don't claim that kind of knowledge. I program mostly in Perl, and you can be damn sure I've never looked at it's source code.
-
@NorseLaQuet said:
Well, next time instead of writing a program, simply ask the computer what to do instead... I don't think you are getting what I am saying here, we have to conform to how computers understand things to get our programs to run. You are developing code that the computer will understand, and in order to do that you should always take into consideration what affects your code has on the computer's resources.
You really seem to miss my point. Obviously we are developing for computers, but we need to make the languages conform to how humans think, not computers. The fact that you are arguing against this makes me think you are really ignorant, as the last 40 years of language development has been towards this goal. The point is that you shouldn't have to consider what effects your code has on the computer because those things should be abstracted away as much as possible.
@NorseLaQuet said:
Wow. This is great. For all of you who don't want to sift though this paragraph; he just basically said: "High level programmers should not make their code resource aware, and should go about consuming as much resources as they want of the system as long as it maintains readability to other humans." If google thought like you, I doubt gmail and google reader would be such quick applications.
Yes and no. Programmers should not consume as many resources as possible because they shouldn't be worrying about resources for the most part. If extensive profiling shows inefficiencies that are worth addressing, then they should be. However, developer time is expensive compared to CPU time, so the that should be taken into account when deciding if an efficiency is worth removing. Oh, and this is exactly what Google does, by the way. They design at an extremely high-level for the goals of scalability and power, disregarding all the lost cycles at the lower level. Have you really never heard about Google's hardware strategy? They just throw lots of custom-built machines at the problem.
@NorseLaQuet said:
I thought that high level developers should not worry about what data structure their VM decides to put their magical re-sizable arrays? So per your, argument if the VM decides to use a vector, your arrays should be 0-indexed and if the VM chooses a linked list it should be 1-indexed. That would be confusing. Why should there be a difference between how your index things just because one is native pointer arithmetic and the other is a more complex data structure?
I never argued this. Where in the fuck are you getting this from? High-level developers should not care what low-level data structure is used. My argument is the exact opposite of this. You are the one who is insisting 0-based indexes make sense because that is what is used with pointer-offsets. I am arguing that whatever is used underneath should not affect the high-level abstraction.
@NorseLaQuet said:
And again, indexes are not abstractions. I think you are slightly daft here. All variables in the program are referred to by memory offsets. Every single one. An index is simply an offset multiplied by the size of the datatype passed the first element of the array.You should read the chapter about pointers in sams teach yourself C++ in 21 days again, and I think you might pick up on some new ideas for you.
Yes, indexes are abstractions, just as variables are. All data is most likely being stored as an electrical charge in a capacitor but we're not going to start referencing voltage changes in our source code just because that is what a computer "knows". I know how indexes work in C++. That has nothing to do with what an index is. A variable is a unique name for a piece of data. An array is a unique name for a sequence of discrete pieces of data. An index is a unique numerical identifier for one of those pieces of data. Nothing in that definition mentions memory offsets and pointers. Your inability to understand this simple concept is stunning.
@NorseLaQuet said:
I still don't get it. Why would you want 1-indexed arrays? Why? Just because its 'more natuaral' to new developers? Like I said already, I have been programming for a hell of a long time, and most of my development has been with low level languages. It would be just plain stupid if high level language developers decided one day, in order to accommodate young programs, to make my life more difficult.
One-based indexes would make array access more natural for everyone. Just because you have learned a rather simplistic way of indexing and seem incapable of learning anything new doesn't mean the state of the art should not advance. That would be just as stupid as someone arguing that we don't need OOP because it will only make life easier for new developers.
@NorseLaQuet said:
You, my friend, have just made my list of top 10 morons.
Considering how inflexible your mind seems, I choose to be flattered by this.
@NorseLaQuet said:
The reason they need to know is because they need to have respect for the effects code has on the host machine. Not to the individual components level, but everything from the syntax to how their code is ran by the processor. I think you have a very shitty attitude to say that only 0.1% programmers are as smart as you. Grow the fuck up, for the love of God.
Respect for the effects code has on the host machine? There is like a goddamn religion to you. Additionally, I do know a lot about systems from the top-down and I still consider myself only in the top 5% or so of developers in this regard. I am striving to be in that top 0.1% but I know it will take a lot of effort. Additionally, I only want to learn these things because they interest me. Knowing low-level details has not really helped me in high-level programming at all. For actual software development, my concerns are on reducing defect rate, getting requirements clearly communicated between stakeholders, implementing the solution rapidly, testing thoroughly with lots of feedback from stakeholders and deploying reliably. I don't want my software to run slowly and I generally take some time to make sure it performs well enough for the requirements and that it can scale as well. However, I really don't pay much attention to low-level details because it's cheaper just to buy 2x as many servers than it is to waste my time on low-level details.
-
Wow. This kind of craziness is exactly why I love the daily WTF. Thank you, NorseLaQuet, for providing some of the most ridiculous statements I've read in a while (since the last zzo post, in fact.)
You sound like a seriously scared data entry clert, threatened by the idea that someone might take the 0-based indexes away, thereby making your skills obsolete, since the compiler can do the task of translating from logical addresses to physical memory much better, faster and with greater reliability.
Why are you so stuck on this notion that you need to write code the way the computer expects it? Have you never seen any functional languages? Of course, there is a need for some (absolutely tiny amount of) hardware level code, but those have fortunately become very specialized areas. Why aren't you rebeling against the C++ language and coding in assembly instead?
For comparison (not a very fair one, I'll grant you that,) here's a common algorithm implemented in C and in Haskell.
3.1 Quicksort in Haskell
qsort [] = []
qsort (x:xs) = qsort (filter (< x) xs) ++ [x] ++ qsort (filter (>= x) xs)[edit]3.2 Quicksort in C
void qsort(int a[], int lo, int hi) {
{
int h, l, p, t;
if (lo < hi) {
l = lo;
h = hi;
p = a[hi];
do {
while ((l < h) && (a[l] <= p))
l = l+1;
while ((h > l) && (a[h] >= p))
h = h-1;
if (l < h) {
t = a[l];
a[l] = a[h];
a[h] = t;
}
} while (l < h);
t = a[l];
a[l] = a[hi];
a[hi] = t;
qsort( a, lo, l-1 );
qsort( a, l+1, hi );
}
}Notice a difference? Bingo. The C code is all worried about mundane tasks, where to store items, how items are indexed and other "pointless" work that's only taking time away from thinking about *what* it is that you want the program to do. Here's some more information on the examples and the Haskell language: http://www.haskell.org/haskellwiki/Introduction#Quicksort_in_Haskell
@NorseLaQuet said:
I think you have a very shitty attitude to say that only 0.1% programmers are as smart as you.
That actually was a generalization and not a statement about his abilities. I think that anyone with a CS degree should have a decent understanding of those areas though. Everything mentioned was covered in various compiler design, operating systems and CPU architecture lectures offered at my university. Knowing how this works is no justification for actually developing software in backwards low-level ways, however. Understand it, and move on to high level languages that don't make you deal with all the crap that goes on during compilation / interpretation / execution of code, such as calculating array indexes.
-
@morbiuswilters said:
@NorseLaQuet said:
Well, next time instead of writing a program, simply ask the computer what to do instead... I don't think you are getting what I am saying here, we have to conform to how computers understand things to get our programs to run. You are developing code that the computer will understand, and in order to do that you should always take into consideration what affects your code has on the computer's resources.
You really seem to miss my point. Obviously we are developing for computers, but we need to make the languages conform to how humans think, not computers. The fact that you are arguing against this makes me think you are really ignorant, as the last 40 years of language development has been towards this goal. The point is that you shouldn't have to consider what effects your code has on the computer because those things should be abstracted away as much as possible.
I have already stated that high level languages are a good thing. They allow you to write code quickly that meets specific demands. But no matter how far away you get from machine language, you will always be running on the same finite resources that every program (weather it be executed via VM or assembled into machine language) has to face. I think you are being ignorent here, by saying that high level language developers should not care about memory or performance.
You say that developers time is more costly then CPU cycles; and that is true. But if you require desktop upgrades on each computer your program runs; or force your clients to waste time waiting for your program to complete an operation - you are ultimuitly wasting even more money.
@NorseLaQuet said:
Wow. This is great. For all of you who don't want to sift though this paragraph; he just basically said: "High level programmers should not make their code resource aware, and should go about consuming as much resources as they want of the system as long as it maintains readability to other humans." If google thought like you, I doubt gmail and google reader would be such quick applications.
Yes and no. Programmers should not consume as many resources as possible because they shouldn't be worrying about resources for the most part. If extensive profiling shows inefficiencies that are worth addressing, then they should be. However, developer time is expensive compared to CPU time, so the that should be taken into account when deciding if an efficiency is worth removing. Oh, and this is exactly what Google does, by the way. They design at an extremely high-level for the goals of scalability and power, disregarding all the lost cycles at the lower level. Have you really never heard about Google's hardware strategy? They just throw lots of custom-built machines at the problem.
Ah, so now you are saying that high level language developers _should_ know about memory management, but only waste their time dealing with it after they profile their code at the end of development? Well, here is the problem: they will have to have the knowledge of being able to profile their code or employ good resource management before they can do what you suggested. And what if their program's architecture does not lend itself well to good resource management because they never worried about it until at the very last minute? So you are asking them to waste even more time re-writing their code to be resource aware at the last minute instead of designing their system's architecture to manage resources well from the beginning. I see...
@NorseLaQuet said:
I thought that high level developers should not worry about what data structure their VM decides to put their magical re-sizable arrays? So per your, argument if the VM decides to use a vector, your arrays should be 0-indexed and if the VM chooses a linked list it should be 1-indexed. That would be confusing. Why should there be a difference between how your index things just because one is native pointer arithmetic and the other is a more complex data structure?
I never argued this. Where in the fuck are you getting this from? High-level developers should not care what low-level data structure is used. My argument is the exact opposite of this. You are the one who is insisting 0-based indexes make sense because that is what is used with pointer-offsets. I am arguing that whatever is used underneath should not affect the high-level abstraction.
No, I agree with you there. If I am developing in PHP I should not have to worry about weather my array's are vectors or lists. That being said, why does 0-indexing have to be about the low level details? I used the 0-indexing argument initially because it makes life easier for low level developers who use high level languages as well. But why do you insist that 1-indexing things makes it more or less high level? Look; no matter what, people who just learn C# are going to have to learn alot about programming in order to write code. Why is it so hard for them to learn how to 0-index things? 0-indexing made sense to me when I learned C++ just fine! Did you personally struggle with 0/1 indexing when you were learning to program?
We should start a poll: Who had issues with 0 indexing when they began programing?
@NorseLaQuet said:
And again, indexes are not abstractions. I think you are slightly daft here. All variables in the program are referred to by memory offsets. Every single one. An index is simply an offset multiplied by the size of the datatype passed the first element of the array.You should read the chapter about pointers in sams teach yourself C++ in 21 days again, and I think you might pick up on some new ideas for you.
Yes, indexes are abstractions, just as variables are. All data is most likely being stored as an electrical charge in a capacitor but we're not going to start referencing voltage changes in our source code just because that is what a computer "knows". I know how indexes work in C++. That has nothing to do with what an index is. A variable is a unique name for a piece of data. An array is a unique name for a sequence of discrete pieces of data. An index is a unique numerical identifier for one of those pieces of data. Nothing in that definition mentions memory offsets and pointers. Your inability to understand this simple concept is stunning.
In my eyes the lowest level language is machine language, not individual charges in components. And machine language uses offsets to address memory, although like you pointed out, they dont have symbols.
@NorseLaQuet said:
I still don't get it. Why would you want 1-indexed arrays? Why? Just because its 'more natural' to new developers? Like I said already, I have been programming for a hell of a long time, and most of my development has been with low level languages. It would be just plain stupid if high level language developers decided one day, in order to accommodate young programs, to make my life more difficult.
One-based indexes would make array access more natural for everyone. Just because you have learned a rather simplistic way of indexing and seem incapable of learning anything new doesn't mean the state of the art should not advance. That would be just as stupid as someone arguing that we don't need OOP because it will only make life easier for new developers.
With OOP you dont have to re-learn years of using arrays with 0-indexes. I can get used to 1-indicies, I'm sure. It will take a while and I will encounter many stupid bugs along the way, but I can get used to it. But then it will just make switching languages more confusing, and it will also make life harder for native 0-indexed developers
@NorseLaQuet said:
You, my friend, have just made my list of top 10 morons.
Considering how inflexible your mind seems, I choose to be flattered by this.
I was out-of-line right there, sorry for the offense.
@NorseLaQuet said:
The reason they need to know is because they need to have respect for the effects code has on the host machine. Not to the individual components level, but everything from the syntax to how their code is ran by the processor. I think you have a very shitty attitude to say that only 0.1% programmers are as smart as you. Grow the fuck up, for the love of God.
Respect for the effects code has on the host machine? There is like a goddamn religion to you. Additionally, I do know a lot about systems from the top-down and I still consider myself only in the top 5% or so of developers in this regard. I am striving to be in that top 0.1% but I know it will take a lot of effort. Additionally, I only want to learn these things because they interest me. Knowing low-level details has not really helped me in high-level programming at all. For actual software development, my concerns are on reducing defect rate, getting requirements clearly communicated between stakeholders, implementing the solution rapidly, testing thoroughly with lots of feedback from stakeholders and deploying reliably. I don't want my software to run slowly and I generally take some time to make sure it performs well enough for the requirements and that it can scale as well. However, I really don't pay much attention to low-level details because it's cheaper just to buy 2x as many servers than it is to waste my time on low-level details.
Imagine you knew nothing other then C#. 'new' is a black box you blindly use to create variables. References are "just how it works" to you, and you are contently pissed off why structs are passed by value because you have no idea what the difference is between a pointer and a variable. Now, what strategies of optimization will you use? You don't know anything about the heap or the stack or about any other resource-management idea that has been abstracted out for you, and you do not understand how expensive strings are to manipulate. Would you really know the first place to start if you found out your program takes up 40/50MB of memory idle?
I'm not asking you to waste time on low level details. But simply by virue of knowing about their existence, I'm sure you make subconscience decisions about how you write your code that makes your programs run faster on the host machine all of the time. If you no longer had that knowledge, you would be doomed to write code that did not run very quickly, but not have the first clue why.
I came off a bit harsh on my last post and I apologize. But please consider what I am saying before you impose on us that 1-indexing things somehow helps people program.
-
@Nandurius said:
Notice a difference? Bingo. The C code is all worried about mundane tasks, where to store items, how items are indexed and other "pointless" work that's only taking time away from thinking about what it is that you want the program to do.
Meanwhile the C code is actually more useful than a basic insertion sort. The Haskell code isn't. Functional languages like Haskell works on lists rather than arrays. Lists don't allow random indexing, meaning the speedup gained from divide-and-conquer algorithms like quicksort is negated by the fact that the actual dividing takes O(n) time, due to having to decompose the list element by element with head or tail recursion.
This is where knowing a bit about the 'mundane' tasks underneath comes in handy. "What" I want the program to do may be important, but it means nothing if the solution I end up with is not usable in practice due to performance issues that are so substantial that just tossing more powerful hardware at the problem doesn't solve them.
Also, I can't help but chuckle at the fact that you argue to move away from the lower level math of how a computer works and then end up heralding functional programming, which is even more math-like and requires a totally different (and to many people unnatural) mindset to work with.
-
@tster said:
6. Vector and Matrix mathematics is 0 indexed.
No... no it isn't. If F is a field, F¹ is the field itself, F² the two-dimensional vector space over the field... F° can only be considered the trivial set consisting only of the zero vector... it is not too useful. A 1x1 matrix has one row and one column, a 0x0 matrix doesn't even make any sense. So doesn't a vector with 0 components.
Also, the natural numbers start at one.
-
@derula said:
F° can only be considered the trivial set consisting only of the zero vector ... it is not too useful.
since you started talking about fields: how do you define a field and or what properties does a field have ?
@derula said:
Also, the natural numbers start at one.
wow ... that is one realy strong argument ... i cant wait to see how people reply to that one :) ...
-
Programing languages like C and C++ are designed to abstract the hardware without sacrificing the ability to manipulate said hardware at a low level. Hence why most operating systems are written in C, with only a comparatively small amount of assembly for interrupts, traps and other super-low-level things to jump into. 0-based offsets to pointers are used in these programming languages because the hardware uses 0-based offsets. Arrays also use 0-based offsets because arrays in these languages are generally used as shorthand for pointers. Languages like Java and C# could use 1-based indexing, but this would break convention, make it even harder to interface between these languages and code written in existing languages and make it difficult to represent things like cartesian planes.
-
I'm bored. Can we discuss indentation styles now?
-
@NSCoder said:
I'm bored. Can we discuss indentation styles now?
Seconded ... And while we're at it we should really decide whether the curly brackets go behind the "if" statement or under it ...
-
@bstorer said:
PEOPLE DON'T START COUNTING AT ZERO!
<font face="Arial, Helvetica, sans-serif" size="2"></font><font face="Arial, Helvetica, sans-serif" size="2">You know, you come from nothing - you're going back to nothing.</font>
<font face="Arial, Helvetica, sans-serif" size="2">What have you lost? </font>
<font face="Arial, Helvetica, sans-serif" size="2">Nothing!</font>
-
@Nelle said:
how do you define a field and or what properties does a field have ?
A field is a set together with to operations. The set together with the first operation (usually referred to as +) forms an Abelian group (the identity is usually called 0). The set excluding 0 together with the second operation (usually called * or ·) is also an Abelian group, its identity is usually called 1. The second operation is distributive over the first one.
A complete, ordered field is isomorphic to the real numbers.
The definitions on Wikipedia look a bit differently (one is completely axiomatic), but should be equivalent. What's your point here, actually?
-
@Nelle said:
Seconded ... And while we're at it we should really decide whether the curly brackets go behind the "if" statement or under it ...
Anybody who puts the curly bracket to the right of the 'if' statement instead of a new line should be shot, I am afraid to say.
-
@DrJokepu said:
Anybody who puts the curly bracket to the right of the 'if' statement instead of a new line should be shot, I am afraid to say.
I suppose you're paid per line of code?
I don't like these brackets at all, I find Basic / Ada / Pascal / Ruby way more beautiful in this concern. Where I like ruby syntax most.
-
You might as well use Python and get rid of all block delimiters.
-
@DrJokepu said:
Anybody who puts the curly bracket to the right of the 'if' statement instead of a new line should be shot, I am afraid to say.
You're going to have to get a gun first, Briton! Why don't you come here and tell me to my face that curly braces belong underneath the block and not to the right?
-
The worst I've seen - and this was quite recently - was something like this:
This was aggravated by total lack of consistency - or perhaps "sanity" - of indentation throughout the rest of the code.if (clue > 0)
{
dosomething();
dosomethingelse();
variablewithaareallylongname = hugeexpressionthatdisappearstorightofthescreen; }
I'll probably post that code here in the Sidebar one of these days.
-
@DrJokepu said:
Anybody who puts the curly bracket to the right of the 'if' statement instead of
a new line should be shot, I am afraid to say.The Tcl community would like to have a word with you, kind sir.
-
The only people worse then those dirty put-brace-to-the-right-of-the-if-statement (just kidding ;)) are those who follow no conventions at all. You know, those bits of code that you _know_ where copied and pasted right off of 10 different php manual user comment pages and then thrown together in a functionless, structureless mess of code that makes you want to vomit each time you sift though it? Those piss me off...
I really don't care what structure you use, as long as it is consistent and is just like mine.
-
@Zecc said:
The worst I've seen - and this was quite recently - was something like this:
if (clue > 0)
{
dosomething();
dosomethingelse();
variablewithaareallylongname = hugeexpressionthatdisappearstorightofthescreen; }
Looks like a good compromise to me ...
-
@derula said:
What's your point here, actually?
No point, just wanted to check whether you know what you are talking about ...
you passed, well done ...
vector and matrix mathematics are not 1 indexed, they are not 0 indexed, you are free to choose your indexing (afaik) ...
you were refering to the order of the vector/matrix ...
-
@Zecc said:
The worst I've seen - and this was quite recently - was something like this:
if (clue > 0)
{
dosomething();
dosomethingelse();
variablewithaareallylongname = hugeexpressionthatdisappearstorightofthescreen; }Its quite fitting actually, because it won't do anything if it doesn't have a clue what to do.
-
@morbiuswilters said:
The offset thing has nothing to do with indexes, it has to do with poor abstraction of the memory model used underneath. Counting starts at 1. That's how it works, okay?
I don't know about anyone else here, but whenever I think about array indices, I don't think of them as representing the "count" of the elements. Ever since I first started programming (incidentally in C), I've just thought at it as, "the element offset N*sizeof(element) from the beginning of the array," and "array," to me, has always just meant any contiguous block of virtual memory used for storing a set of data. Zero-based indexing seems perfectly natural in my mind. It also makes pointer arithmetic much easier to deal with, since the behavior of the array "index" is the same as it would be using pointer arithmetic. I often find pointer arithmetic to be more convenient for certain applications than just using array notation.
-
@PerdidoPunk said:
@morbiuswilters said:
The offset thing has nothing to do with indexes, it has to do with poor abstraction of the memory model used underneath. Counting starts at 1. That's how it works, okay?
I don't know about anyone else here, but whenever I think about array indices, I don't think of them as representing the "count" of the elements. Ever since I first started programming (incidentally in C), I've just thought at it as, "the element offset N*sizeof(element) from the beginning of the array," and "array," to me, has always just meant any contiguous block of virtual memory used for storing a set of data. Zero-based indexing seems perfectly natural in my mind. It also makes pointer arithmetic much easier to deal with, since the behavior of the array "index" is the same as it would be using pointer arithmetic. I often find pointer arithmetic to be more convenient for certain applications than just using array notation.
I'm sorry to say that your experience with C has tainted your mind into believing that the old, archaic and low level practice of 0-indexing is a good thing when in fact it is devil-spawn. You must now cleanse yourself by using the new-and-improved form of 1-indexing in great languages such as VBA or Lua or face execution by high-level-language fanatics. I'm sorry, but your only choice is submission.
-
@duder said:
Why the hell do you think this wouldn't work if arrays were 1-indexed? What effect would that have on anything?
When -1 is the last element you can seamlessly iterate from the 1st to last element and vice-versa, it would obvisouly get f-up'd if there was no 0 index.
for (i = -1; condition; i++) {
// When i = 0 you're f'd.
element = array[i];
}
Plus any operation like array[i + n] would have un-expected results at 0.
0-based indexes just plain make more sense and seem more natural to me.
What exactly do you expect this code to do on a zero-indexed system?
-
@Random832 said:
What exactly do you expect this code to do on a zero-indexed system?
Iterate along array[-1], array[0], array[1], ...Namely, the last element, the first element, the second element, etc.
This only works on "negative-indexable" arrays, of course.
Does this add anything to the conversation? I'm not sure.
You could define array[0] as being the last element of the array, array[-1] as being the penultimate, etc...
-
@Zecc said:
@Random832 said:
What exactly do you expect this code to do on a zero-indexed system?
Iterate along array[-1], array[0], array[1], ...Namely, the last element, the first element, the second element, etc.
This only works on "negative-indexable" arrays, of course.
Does this add anything to the conversation? I'm not sure.
You could define array[0] as being the last element of the array, array[-1] as being the penultimate, etc...
It's not clear to me why one would ever want to use negative indexing and ordinary indexing in the same loop, which is the only situation where you'd get a significant problem from running over 0.
-
@Random832 said:
It's not clear to me why one would ever want to use negative indexing and ordinary indexing in the same loop, which is the only situation where you'd get a significant problem from running over 0.
Circular buffers come to mind, and even so it's not a very good example of use of negative indexes.Circular buffers may rise a point in favour of zero-based indexing though. You can just update your index like so:
read_index = (read_index + 1) % BUFFER_SIZE
instead ofread_index = (read_index + 1) % BUFFER_SIZE + 1
You can even use a binary AND if your buffer size is a power of 2.
-
@Zecc said:
Wrong. With a 1-based index, you do this:Circular buffers may rise a point in favour of zero-based indexing though. You can just update your index like so:
read_index = (read_index + 1) % BUFFER_SIZE
instead ofread_index = (read_index + 1) % BUFFER_SIZE + 1
read_index = read_index % BUFFER_SIZE + 1
which still has one increment and one mod; it's no less efficient.
