As a solid example of this... A fellow student was working on a problem that had a key-value mapping, but instead of storing them in a hash table/map/whatever the language wants to call it, he was storing them as pairs in a list and complaining about the performance on a large data set.
I asked him why he wasn't just storing it in a hash table instead. His answer: "Because I sometimes need to iterate over it and get both the key and the value"
My brain had to sit and parse what he'd said for a few moments, before I realized what the heck he was talking about. In all of the data structure courses, he'd been taught "A hash table hashes the key, and stores the value in the corresponding slot". In that mental model, there's no way to retrieve the key, only to retrieve the value given the key.
I explained to him that real-world implementations do do that, but also store the key along-side the value, so that you can still iterate across it. You could see the look of amazement wash over him, and then he frustratingly declared "Why the hell didn't they mention that?!"
What does that have to do with academia? That's just having an overly simplified mental model of something, which all humans do when learning any new thing, whether through a lecture, a random stack overflow question, the compiler manual, or through pure experimentation.
Academia carries with it a larger amount of authority than a random programming forum. Students have the expectation that the academic staff is generally knowledgeable and wise and what they say in all probability is very important, has to be remembered and followed (even if you don't quite understand why yet but perhaps you will in the future).
I agree. And yet, this seems to be the rare type. Often it's just a few people in the staff that are trying to do things the right way, for the others it's simply a nice job (with few responsibilities and seemingly no obligations). That's what I've been trying to get across. Teaching is a sensitive job with far-reaching consequences, yet more often than not people don't take it seriously and don't care what their students will carry with them into the life when they leave the walls of that academic institution.
They probably did mention that, perhaps he wasn't paying attention? Besides, unless you have perfect hashing, you're bound to have a hash collision at some point. How did he expect a hashmap to work in that case, without also keeping track of the key? If he never asked that question he doesn't understand hashing either.
I was in the same lecture, it definitely wasn't mentioned. I'd been hacking on Perl for years before starting school, so I already "knew it in my heart" how it worked in practice. Just one of those little but critical details where something important got missed.
And yes, when you've got a complete understanding, it seems quite obvious that the key has to be stored with it. That's why I got it. He'd just learned it though, and there were still those gaps in his knowledge that he would have carried for a long time until someone else helped point out the missing piece (or he had decided to sit through and make sure he understood everything)
I asked him why he wasn't just storing it in a hash table instead. His answer: "Because I sometimes need to iterate over it and get both the key and the value"
My brain had to sit and parse what he'd said for a few moments, before I realized what the heck he was talking about. In all of the data structure courses, he'd been taught "A hash table hashes the key, and stores the value in the corresponding slot". In that mental model, there's no way to retrieve the key, only to retrieve the value given the key.
I explained to him that real-world implementations do do that, but also store the key along-side the value, so that you can still iterate across it. You could see the look of amazement wash over him, and then he frustratingly declared "Why the hell didn't they mention that?!"