Maybe if languages get more high level so you don't see pointers used behind the scenes, but C has stood the test of time so I think they're here to stay.
(Note: I'm assuming references don't count as pointers.)
I think most programmers today don't know what a pointer is. Between VB, Java, and PHP programmers, I'm fairly certain that programmers using pointer-capable languages are in a fairly small minority.
What's scarier, a fair number of those programmers don't actually understand pointers, despite using them daily. True story: I had a friend taking EE who had to put some engineering-oriented C under his belt, and he never actually grasped the concept (despite using strings and arrays in his programs). I'm fairly sure malloc(3) would have confused him, and pointer arithmetic would have blown his mind. This was more the fault of the course for never explaining the concepts, but it makes me wonder what fraction of C programmers get a shallow introduction like that.
This does explain the number of buffer overflows out there...
[NB: At the time I made this comment, I had disagreed with the claim. One day, jyte will keep track for me.]
Good argument. I was only considering the fact that current CS undergrads are definitely learning what a pointer is[1], but the majority of today's programmers don't actually come from that background, and there's no reason to think that's gonna change in ten years. So, yeah, okay, this claim has legs.
D'A
[1]: Well, they're being *taught* what a pointer is, which is possibly distinct.
I'm afraid this has already happened. I know many CS undergrads that never took C or C++. If you count all of the PHP hackers out there as programmers then I'm sure this has already happened.
And why do we need to know what pointers are? Languages have evolved to the point where that knowledge is now irrelevant. Moreover, the concept has been framed in a new light with new terms. The use of "pointers" is still there, just under a different moniker.
Oops, didn't see Steven's post until after I submitted...
First, I'm not in the camp of PHP hackers. I can / do code in PHP when necessary but I'm not a fan boy. As much as the hardcores despise the less "low-level" languages it doesn't it doesn't make their statements true.
C and C++ are history as far as client facing apps go. The low-level control it offers is not needed in todays computing (at least as far as web development goes), there are many more viable alternatives...
Not too mention, weren't the C and C++ devs called "hacks" by the assembly coders back in the day? And the assembly devs called "hacks" by the punch card folks back in the day?
Don't be so elitist... As far as today's coding goes, malloc and pointers (at least their definition) are out-dated - and as far as malloc is concerned - laughable...
Well, the big reason every programmer ought to know what a pointer is, is that references aren't going away, and references are just pointers in drag with all the arithmetic hidden away.
A programmer who fails to understand pointers is not going to understand the difference between a reference, a shallow copy, and a deep copy. The result is PHP's argument-passing semantics (deep copy everything).
The word pointer may become obsolete, and the bookkeeping has been streamlined, but I agree the term reference applies to the same thing. I also agree understanding references is a concept people need to grasp well to avoid mistakes.
I like to explain it as pigs and leashes. The pig is your object and the leash is the variable. When you use your pig as an argument in a function call, that other function is adding hooking it's own leash onto the same pig for the duration of the call.
So the thing to remember is if the called function is going to make bacon with it's pig (e.g., like doing math on members of a "rect" that was passed in) then when the original function is in for a shock when it goes to take it's pig for a walk.
It seems sort of obvious but a lot of people's first impression is passing an int and passing a rect to a function look exactly the same, so why would they assume they behave any differently.
I agree with this claim, because I agree that more casual programmers using casual languages will enter the field; and in addition to them, more serious programmers will be using higher-level languages more and more often.
Hardware, embedded, and low-level programmers will know what a pointer is because it is, really, a trivial and concept at the hardware level. Those who learn low-level or hardware languages will know what pointers are because they will have to.
I never understood the confusion around them, but then again maybe I was taught the correct way the first time.
Discussion (11)
Maybe if languages get more high level so you don't see pointers used behind the scenes, but C has stood the test of time so I think they're here to stay.
(Note: I'm assuming references don't count as pointers.)
I think most programmers today don't know what a pointer is. Between VB, Java, and PHP programmers, I'm fairly certain that programmers using pointer-capable languages are in a fairly small minority.
What's scarier, a fair number of those programmers don't actually understand pointers, despite using them daily. True story: I had a friend taking EE who had to put some engineering-oriented C under his belt, and he never actually grasped the concept (despite using strings and arrays in his programs). I'm fairly sure malloc(3) would have confused him, and pointer arithmetic would have blown his mind. This was more the fault of the course for never explaining the concepts, but it makes me wonder what fraction of C programmers get a shallow introduction like that.
This does explain the number of buffer overflows out there...
[NB: At the time I made this comment, I had disagreed with the claim. One day, jyte will keep track for me.]
Good argument. I was only considering the fact that current CS undergrads are definitely learning what a pointer is[1], but the majority of today's programmers don't actually come from that background, and there's no reason to think that's gonna change in ten years. So, yeah, okay, this claim has legs.
D'A
[1]: Well, they're being *taught* what a pointer is, which is possibly distinct.
I'm afraid this has already happened. I know many CS undergrads that never took C or C++. If you count all of the PHP hackers out there as programmers then I'm sure this has already happened.
And why do we need to know what pointers are? Languages have evolved to the point where that knowledge is now irrelevant. Moreover, the concept has been framed in a new light with new terms. The use of "pointers" is still there, just under a different moniker.
Oops, didn't see Steven's post until after I submitted...
First, I'm not in the camp of PHP hackers. I can / do code in PHP when necessary but I'm not a fan boy. As much as the hardcores despise the less "low-level" languages it doesn't it doesn't make their statements true.
C and C++ are history as far as client facing apps go. The low-level control it offers is not needed in todays computing (at least as far as web development goes), there are many more viable alternatives...
Not too mention, weren't the C and C++ devs called "hacks" by the assembly coders back in the day? And the assembly devs called "hacks" by the punch card folks back in the day?
Don't be so elitist... As far as today's coding goes, malloc and pointers (at least their definition) are out-dated - and as far as malloc is concerned - laughable...
Well, the big reason every programmer ought to know what a pointer is, is that references aren't going away, and references are just pointers in drag with all the arithmetic hidden away.
A programmer who fails to understand pointers is not going to understand the difference between a reference, a shallow copy, and a deep copy. The result is PHP's argument-passing semantics (deep copy everything).
The word pointer may become obsolete, and the bookkeeping has been streamlined, but I agree the term reference applies to the same thing. I also agree understanding references is a concept people need to grasp well to avoid mistakes.
I like to explain it as pigs and leashes. The pig is your object and the leash is the variable. When you use your pig as an argument in a function call, that other function is adding hooking it's own leash onto the same pig for the duration of the call.
So the thing to remember is if the called function is going to make bacon with it's pig (e.g., like doing math on members of a "rect" that was passed in) then when the original function is in for a shock when it goes to take it's pig for a walk.
It seems sort of obvious but a lot of people's first impression is passing an int and passing a rect to a function look exactly the same, so why would they assume they behave any differently.
I can only hope. More annoying than endianness
Pointers are related to lvalues. As such, they may exists in languages where once does not expect them.
For example, pointers in Javascript!
Tricky, convulated, unorthodox, evil (and untested):
as in http://virteal.com/DebugDarling
I agree with this claim, because I agree that more casual programmers using casual languages will enter the field; and in addition to them, more serious programmers will be using higher-level languages more and more often.
Hardware, embedded, and low-level programmers will know what a pointer is because it is, really, a trivial and concept at the hardware level. Those who learn low-level or hardware languages will know what pointers are because they will have to.
I never understood the confusion around them, but then again maybe I was taught the correct way the first time.