1-based counting was ``the norm'' for thousands of years. Years begin at 1. The Bible counts chapters and verses from 1. Programming languages before C started arrays from 1 or a user-defined index.
Only a few answers mention that some programming languages let you start from 1. This should be filled with answers saying ``1-based arrays used to be the norm and C hackers came along and forced everyone to use the C way because they get confused if you let them choose the index.'' Stupid questions do not bother me, but wrong answers do. Stack Overflow and Stack Exchange are spreading wrongness into the world. They are reducing the amount of truth on the Internet.
They all say that arrays count from 0 and nobody can change it because it would ``confuse'' people. This is the C mentality. They want to force their 0 on thousands of years of human history and on every non-C-based programming language. They want everyone else to cater to them because they are too dumb. Pascal programmers can learn and use C. They don't like it, but they can get used to it. C programmers don't want to use Pascal because it's not C.
Stop catering to the idiots. They are not good programmers if they get confused by simple concepts like array base. Kids using QBasic and Pascal can understand it, but these C ``expert hackers'' can't. We should stop dumbing down our languages and debasing important computer science concepts because some people are stupid.
Name:
Anonymous2017-08-04 4:53
C arrays start from zero, because they are syntax sugar for pointers: Pointer to X, with X[0] being the first element in the array. You can also refer to element behind the array/points X[-1] refer to element one behind X/X[0] X[-2] refers to element two behind X/X[0] C translates this to *(&X-1),*(&X-2)
Name:
Anonymous2017-08-04 5:48
Zero-based arrays are the only option that makes sense within the context of C. One of the main principles of C is that array element access is syntactic sugar for pointer arithmetic. This is the real reason why arrays in C are so frequently ``unsafe" and it isn't plausible to implement array bounds checking - because there's many data items that are not declared as arrays, but yet have reason to be accessed like they are, and providing bounds checking for data items declared as arrays would likely lead to more errors when dealing with ``array-like objects" because programmers wouldn't learn to be cautious when dealing with indexing.
I do actually agree with the premise that 1-based arrays (or even better, custom array indexing) can be preferable for application programming. That's why so many earlier languages did use 1-indexed arrays. But to express incredulity at the prevalence of zero-based array indexing only demonstrates historical ignorance. Zero-based indexing may not be ideal, but there is a coherent reason why it's so widely used. C was a big deal. It both offered performance sufficient for writing system modules and utilities without resorting to ASM, and was highly portable. That was one of the keys to the success of Unix, that it didn't have to be completely rewritten when porting to a new platform (and unlike today, there were a lot of platforms to consider in those days - nowadays, for ``general purpose" software, pretty much only x86 and ARM need to be considered). And nobody wanted to add or replace core Unix features in anything other than C, because it would reduce the portability of the operating system as a whole. This ultimately led to C and Unix becoming synonymous, and furthermore, resulted in many people having some exposure to C; as a consequence of Unix proliferation, C became popular as an applications language as well as a systems language, even though it wasn't ideal for the former in any aspect other than portability. C was so popular and well-known that many future languages (Java, JavaScript, CSS, PHP, and Perl, to name a few) used a syntax very much like C, including zero-based arrays, even though the main justification for zero-based arrays (that being pointer arithmetic) was not present in many C-derived languages. But it's what programmers are familiar with.
I do agree that C (and modern computing in general) is in some ways a step backwards. However, StackOverflow is a site intended for programmers to seek advice from other programmers. And most programmers are paid for being able to write working code in the languages that exist today, not for knowing the history of how those languages came to be. That information can be useful, certainly, and its absence is a serious flaw in programming education (for a specific example, my education was so focused on C-style syntax and OOP that it took me several years to really fully understand the significance of structured programming - programming courses largely overlook that there ever was such a thing as non-structured programming.) But it's a mistake to expect programmers as a group to be familiar with the history and philosophy of programming. That's simply not the culture we live in. People who began programming after the Unix/C revolution simply aren't aware of what life was like before. And they're not trained to think ``is this really the most logical way to do things?", rather they're trained to write code in the languages that are used, not the ones that they wish existed and were used.
>>4 0-based arrays leverage core assembler paradigms and world-class optimizations to provide our clients worldwide with robust, scalable, modern turnkey implementations of flexible, personalized, cutting-edge network-enabled e-business application product suite batch solution architectures that accelerate response to customer and real-world market demands and reliably adapt to evolving technology needs, seamlessly and efficiently integrating and synchronizing with our existing legacy infrastructure, enhancing the computing capabilities of our production environments across the enterprise while giving us a critical competitive advantage and taking programming to the next level.
Name:
Anonymous2017-08-04 7:41
Ashley Yakeley Posted November 21, 2013 at 3:15 am | Permalink
Clearly bytes should be one-based: they have 256 possible values, and they are most easily counted 1,2,3…256. I wonder who first came up with the idea of zero-based bytes?
Name:
Anonymous2017-08-04 10:28
Mayans wasn't it?
Name:
Anonymous2017-08-04 10:30
>>6 1..256 can be the range of values of one byte, as can 1000..1255 and -99999..-99744. Any range n..n+255 can be stored in a byte. I don't know why universities don't teach this anymore either.
Name:
Anonymous2017-08-04 11:00
>>4 That article doesn't tell the whole story because languages designed after BCPL and C also start arrays at 1 or an arbitrary index.
These ``Worse Is All You Get Forever'' people say it's ``confusing'' to be able to pick the lower bound. I was never confused when I used QBasic on DOS. I was never confused when I used Pascal. The multi-dimensional arbitrary indexed array is easy to learn in these languages, but all you can learn in C is the 0-based one-dimensional ``decayed to pointer'' array because C arrays are harder for people to understand. The C way is confusing because it is inferior, not because it is superior. C-based languages have worse arrays because the C definition of array makes anything more powerful seem impossible.
The C way is dumbing down programmers and ruining languages.
Name:
Anonymous2017-08-05 1:49
C arrays are not ``hard to understand". C for loops are ``hard to understand", making one of the most common array tasks (iterating over an array) confusing and leading to off-by-one errors and buffer overflows. The intent of the C for loop syntax is to make it ``versatile", by allowing the initialization, test condition, and increment condition to be terminated. However, it makes the most common loop format (iterating by 1 over an integer range) needlessly complex for humans to parse, and while it does allow less common loop structures, it's more readable to just use explicit ifs and gotos. The Pascal and BASIC loop syntaxes are more intuitive, and the use of goto can be used to handle less typical cases.
Name:
Anonymous2017-08-05 2:56
As somewon whomst learned x86 asm before C, zero-based arrays maid perfect sense upon introduction.
The C array is harder to understand than the Pascal or BASIC array even though it's less powerful. We have better ways to do arrays that used to be taught in computer science classes and used by ordinary programmers.
The C books teach something about pointers to the first byte of an element, which is an implementation detail of one possible implementation. They also ``flatten'' variable-length multidimensional arrays into one dimension and you have to use multiplication to get the address, another implementation detail. Arrays are a simple and beautiful computer science concept and all of these complicated implementation details are ugly and get in your way of understanding them. These CS classes are dumbing down programmers by using inferior definitions and teaching methods that make things harder to understand. C is dumbing down people and programming languages.
The pointer arithmetic makes arrays starting from a number besides 0 too hard to understand and C programmers want you to fake multi-dimensional arrays with multiplication, which makes multi-dimensional arrays too hard to understand and use, so these new language creators don't include them in their languages.
C for loops are ``hard to understand", making one of the most common array tasks (iterating over an array) confusing and leading to off-by-one errors and buffer overflows.
Yes they are and this is another problem. The C for loop is also full of implementation details, like whether you add 1 before or after you throw away the result. There are at least 4 different ways to add 1 to the index (i++, ++i, i += 1, i = i + 1). The array and loop together make C even worse.
Name:
Anonymous2017-08-05 7:13
This is like claiming that we should use tau instead of pi. The exact numbers we use for the indices of an array is superficial at best and doesn't affect the implementation or understanding of any algorithm. Asking for it to directly represent data from your domain in your code speaks of an inability to distinguish between the two and map even less trivial differencing concepts from one to the other.
Name:
Anonymous2017-08-05 8:41
>>11 Of course they make sense from a low-level background, because C style arrays are designed to correspond with common machine instructions.
The C books teach something about pointers to the first byte of an element, which is an implementation detail of one possible implementation.
It's my understanding that that is not merely an implementation detail as far as C is concerned, it's a defined part of the language semantics, or at least that arrays must behave as if their elements are stored contiguously in memory. C does place fairly strict requirements on how features are implemented, because C is by design a minimalist language and unless its basic constructs are implemented consistently, more complex features built on top of those constructs won't be reliable. It's not the only way to make a language, but it is in line with the C philosophy. The mistake is in thinking that the qualities that make a low-level systems language will also make a good apping lang or a good scripting lang.
They also ``flatten'' variable-length multidimensional arrays into one dimension and you have to use multiplication to get the address, another implementation detail.
Because that is pretty much a requirement when it comes to treating arrays of arbitrary dimensions (or any object, really) as a block of contiguous bytes. It's an inherent part of how the whole C environment was designed. Not ideal for languages built with other models in mind, but it's perfectly reasonable within the context of C. The problem isn't C, C is perfectly good for its niche, the problem is that so many other languages end up being "C with design patterns", "C for the web", "C for dummies", "C with significant whitespace", "C with lazy evaluation", "C as a markup language" etc, etc.
Name:
Anonymous2017-08-05 21:10
>>14 C arrays force you to think about implementation details and actually prevent you from understanding CS concepts. If you want to use a Pi analogy, the C way would be like measuring the diameter and circumference of a specific circle that someone drew in a notebook and declaring that as the ``Pi circle'' because any other way of calculating Pi is ``confusing'' for ``notebook hackers''. These ``notebook hackers'' also claim the mathematical properties of Pi are ``outdated'' and ``abstract''.
It's my understanding that that is not merely an implementation detail as far as C is concerned, it's a defined part of the language semantics
This makes it hard to understand what an array is. It might be how an array is implemented, but it's not what an array is. An array drawn on paper with a pencil doesn't have anything to do with pointers or contiguous byte blocks. Computer science classes used to teach that you should never confuse a concept with its implementation.
C does place fairly strict requirements on how features are implemented, because C is by design a minimalist language and unless its basic constructs are implemented consistently
Making the semantics more complicated by forcing you to implement features a certain way is the exact opposite of minimalist. Minimalist has minimal requirements on the implementation. Compare the definition of arrays in ISO Pascal and ISO C.
The problem isn't C, C is perfectly good for its niche, the problem is that so many other languages end up being "C with design patterns", "C for the web", "C for dummies", "C with significant whitespace", "C with lazy evaluation", "C as a markup language" etc, etc.
It's about to get even worse because WASM is forcing the ``block of contiguous bytes'' model even more than C does.
Name:
Anonymous2017-08-07 5:57
This has completely drifted from the original topic of the thread, which is about Stack Overflow being wrong and upvoting wrong answers, and harming your understanding. Stack Overflow makes you know less after reading it than before. It replaces truth that you are unsure about with false information. 1-based arrays are the norm for programming languages that aren't based on C. This is because of what an array is and what a high-level language is. Fortran keeps adding more and more array features because arrays as a concept are more powerful than their implementation in any language. The Fortran people know what arrays are and aren't dumbed down by misunderstandings and Stack Overflow answers.
Universities are also part of the problem, because it seems like nobody knows anything anymore except how to use Google and Stack Overflow. Anyone who took a CS class in the 90s and learned Pascal would know right away that these answers are wrong. They are dumbing down their students by teaching inferior and harder to understand C arrays. This has even dumbed down languages like Java. Wrongdoers say things about ``an inability to distinguish between the two and map even less trivial differencing concepts from one to the other'' which is mumbo jumbo for ``people have made compilers to do it since the 1950s, but we're too ignorant of computer science concepts to know it is even possible''. They are saying that ``Worse is Better'' in a very literal sense. Having a worse compiler is not better. Having a worse understanding of computer science is not better. Because the students do not know anything about computer science, ``Worse Is All You Get Forever''.
Unless you're referring specifically to ``high level" arrays that have ``nice" features like bounds checking, arrays are usually implemented in hardware. Basically, any architecture with load/store instructions taking register or memory operands, and which uses a pointer representation similar to integers (which, by the way, is not required by the C Standard) has array support at the hardware level. Only very primitive (i.e. pre-1950s) computers lacked those features, requiring that array operations be implemented using self-modifying code, or writing a massive switch statement for every single array. Even then, the address space was just a giant array in terms of how the computer accessed it, but without indirect addressing you basically had to treat it as a bunch of slow registers.
>>32 Only if your hardware actually allows 0 to map to somewhere in physical memory, rather than triggering an internal hardware exception whenever you try to access something at address 0.
Name:
Anonymous2017-08-10 2:29
1-based counting would reduce the amount of off-by-one errors