References are not pointers, and I stand by what I said. Pointers are not needed by most people writing software outside of very specific domains.
References are a related but distinct concept. I can "hold a reference" to something without ever being able to read what its memory address is or change what memory address that reference points to. The power to do that is unnecessary for most programs that are written.
> They exist for a reason.
Did I ever say otherwise?
EDIT: Expanding on the notion of "need". A programmer using a C library "needs" pointers because the C library almost certainly makes use of them. The user may or may not need to use pointers themselves to interact with the library (that is, it may offer an interface based on values and not pointers). A programmer on any OS I can think of will be making use of pointers through similar levels of indirection. As an Erlang hobbyist, the implementation almost certainly uses pointers internally, but as an Erlang programmer I wouldn't use them directly. In order to write a program in Erlang, I never need a pointer, though I may make use of some kind of reference (process IDs are a kind of references, but they are not pointers).
> The power to do that is unnecessary for most programs that are written.
Ok. So don't use that power then. Or use references instead, which are conceptually the same thing.
> Did I ever say otherwise?
You quite clearly stated their purpose was very niche. I think you took my statement a bit to literally, as what I meant to convey was: no, they are not niche.
Edit: after reading your edit, I would like to remind you we were discussing the needs of learning the concept of pointers. While what you mention may not be literal C pointers, that is besides the point (haha) because they (methods of indirection) are conceptually equal.
> Or use references instead, which are conceptually the same thing.
In the same sense that a donut is topologically the same as a coffee mug, sure.
> You quite clearly stated their purpose was very niche.
I did not. I said they weren't needed outside of specific domains, which is not the same as "niche".
> we were discussing the needs of learning the concept of pointers
Per my original comment, no, we were not. I wrote of needing pointers. I said nothing about the needs of learning the concept of pointers.
My comment was, and I stand by this, that pointers are a fantastic example of accidental complexity. They are present in many programming languages, and are a thing people have to use as a consequence but which are not themselves necessary for the problems that many people intend or need to solve. References, which are not the same as pointers except again in the sense of donut = coffee mug, are a more general concept that has broader utility than pointers without the added complexity that pointers bring to the table (though depending on the manner of the references they may bring in their own, see both Python and Java and the unintentionally altered collection values).
The complexity is historic, not accidental. If you start with a linearly organised address space then you need some way to reference the items in it.
The physical address in the linear space [1] isn't just the obvious option, it's the only option. [2] It's a short step from there to indirect addressing via a linear lookup table, and/or simple address arithmetic to find items stored sequentially.
You can only avoid this by adding layers of abstraction which hide these mechanisms.
But you can only do that after the mechanisms are in place. Otherwise your "reference" is just an unimplementable idea with no meaning.
[1] Ignoring hardware paging, because that's usually invisible.
[2] Ignoring hypothetical magic associative O(1) key-value store hardware with the same speed as semiconductor RAM - which could be built at ludicrous expense, but would cause complexity issues of its own.
To be clear I'm using "accidental complexity" in the sense of Brooks. He breaks complexity in software systems, in his No Silver Bullet paper, into two categories: accidental and essential. My contention is that for most programers and programs pointers fall under the category of accidental complexity. That does not diminish their utility, nor mean that they never fall under the category of essential complexity (indeed, having spent most of my career on embedded systems, there are things we could not have done or done as easily without pointers). Just that, for most of the things people want to accomplish when programming a computer, pointers (though often not the broader sense of references) are accidental (i.e. unnecessary) complexity.
Lets not get stuck on defining what niche means. Its meaning has been defined for a while already. Niche = specific domain related. Anyway.
In which ways are references of broader utility? And what is so complex about pointers? The fact that it doesn't hide behind language magic? Well, that you can just ignore: I don't _need_ to see or edit the address it holds.
Funnily enough, I really struggled going to Java and python coming from C++ originally. What do you mean I don't know if I'm getting a copy? The semantics of passing something to a function were so confusing and I was never sure if I got a copy or not. Pointers made so much sense.
I find D's implementation of pointers not only to be fairly easy and straightforward to understand, but quite powerful and useful. They basically fix most of the problems with C's pointers.
The toy virtual machine and language I built in D uses function pointers heavily to implement the machine's opcodes. They made it incredibly simple to program the 'CPU' of the virtual machine. The opcode functions are setup as an array of function pointers.
Whenever a byte that represents an opcode is read, it simply calls the function being pointed to at the corresponding index in the array. It allows for additional opcodes to be easily added without hassle or breaking things. Every other way I tried without pointers was convoluted and didn't work as expected. Using an array of function pointers just works.
No, I don't.
> Pointers, references, whatever you call them.
References are not pointers, and I stand by what I said. Pointers are not needed by most people writing software outside of very specific domains.
References are a related but distinct concept. I can "hold a reference" to something without ever being able to read what its memory address is or change what memory address that reference points to. The power to do that is unnecessary for most programs that are written.
> They exist for a reason.
Did I ever say otherwise?
EDIT: Expanding on the notion of "need". A programmer using a C library "needs" pointers because the C library almost certainly makes use of them. The user may or may not need to use pointers themselves to interact with the library (that is, it may offer an interface based on values and not pointers). A programmer on any OS I can think of will be making use of pointers through similar levels of indirection. As an Erlang hobbyist, the implementation almost certainly uses pointers internally, but as an Erlang programmer I wouldn't use them directly. In order to write a program in Erlang, I never need a pointer, though I may make use of some kind of reference (process IDs are a kind of references, but they are not pointers).