While that may seem like a silly question, if Java and Ruby both lost the data structure entirely, my code would still function. (The frameworks it runs on, not so much.)
It is sort of like a programmer not knowing what a NAND gate is. You could get all crotchety about that, because he couldn't do a single thing without a NAND gate on his current system... but he really doesn't need to know the specifics. Many types of programming (not all, obviously) have abstracted away memory management and have pitiful speed requirements compared to the capacity of hardware (and the bottlenecks don't happen anywhere near application code), and accordingly aside from syntactic inertia there is really not that much of a reason to care about arrays any more than there is to know about your NAND gates.
(Edit: It occurs to me that I could monkeypatch Array in Ruby and replace it with an associative array and my site would probably function fine... Maybe I'll try it just to prove a point.)
It occurs to me that I could monkeypatch Array in Ruby and replace it with an associative array and my site would probably function fine... Maybe I'll try it just to prove a point.
Why bother? Just spend half an hour learning PHP, which works exactly like this. It has a data structure named "array" that is actually an associative array, and which supports both array semantics and hash semantics (and, if you're not careful, will assume one when what you want is the other).
Is this a wise design decision? Yes and no. One less data structure to think about is perhaps easier for beginners. But, as we see here, it also encourages people to remain ignorant of how their data structures actually work. If you ask yourself "would I ever use PHP to teach a data structures class", the answer would seem to be "hell, no" -- which tells you something. And when you do have to think seriously about performance (which, though it often happens too soon, does have to happen eventually) it seems to me that you'd want an array primitive in your toolkit. (At that point, hardcore PHP developers would probably advocate just dropping into C and writing C extensions.)
I'm worried that (according to his stackoverflow profile) a 'Long-time Informix user and developer, experienced in C and Unix (many variants)' asks such a question.
As mentioned in the Reddit comments on this, a stackoverflow question can be edited, and if it is, the most recent editor shows up in the bit you've looked at. And that is this person, who isn't the original questioner.
it is a good intro to the subject, however, Shewchuk does not thoroughly explain the difference beetween lookup/ access time and search time for arrays and linked lists. I like the explanation given by the commenter on stackoverflow
I would find it very odd if this guy didn't know what an array was but did know what a linked list is.
I'm guessing (since I've been there myself at one point) that he thinks a list is just some list in memory and he doesn't understand the internal representation of any of the structures at all.
[+] [-] patio11|17 years ago|reply
It is sort of like a programmer not knowing what a NAND gate is. You could get all crotchety about that, because he couldn't do a single thing without a NAND gate on his current system... but he really doesn't need to know the specifics. Many types of programming (not all, obviously) have abstracted away memory management and have pitiful speed requirements compared to the capacity of hardware (and the bottlenecks don't happen anywhere near application code), and accordingly aside from syntactic inertia there is really not that much of a reason to care about arrays any more than there is to know about your NAND gates.
(Edit: It occurs to me that I could monkeypatch Array in Ruby and replace it with an associative array and my site would probably function fine... Maybe I'll try it just to prove a point.)
[+] [-] mechanical_fish|17 years ago|reply
Why bother? Just spend half an hour learning PHP, which works exactly like this. It has a data structure named "array" that is actually an associative array, and which supports both array semantics and hash semantics (and, if you're not careful, will assume one when what you want is the other).
Is this a wise design decision? Yes and no. One less data structure to think about is perhaps easier for beginners. But, as we see here, it also encourages people to remain ignorant of how their data structures actually work. If you ask yourself "would I ever use PHP to teach a data structures class", the answer would seem to be "hell, no" -- which tells you something. And when you do have to think seriously about performance (which, though it often happens too soon, does have to happen eventually) it seems to me that you'd want an array primitive in your toolkit. (At that point, hardcore PHP developers would probably advocate just dropping into C and writing C extensions.)
[+] [-] tgdavies|17 years ago|reply
[+] [-] presty|17 years ago|reply
I mean, seriously?
[+] [-] parenthesis|17 years ago|reply
[+] [-] d0mine|17 years ago|reply
[+] [-] abl|17 years ago|reply
http://www.youtube.com/watch?v=Wp8oiO_CZZE
it is a good intro to the subject, however, Shewchuk does not thoroughly explain the difference beetween lookup/ access time and search time for arrays and linked lists. I like the explanation given by the commenter on stackoverflow
[+] [-] jcbozonier|17 years ago|reply
I'm guessing (since I've been there myself at one point) that he thinks a list is just some list in memory and he doesn't understand the internal representation of any of the structures at all.