But that's not really the point. I think the point is that there's a need for a sort of onboarding process for people who have never had to deal with some of these basic concepts. For instance, in web development, there's not a lot of need to know much about ownership or memory. The popular languages (Java, PHP, Python) kinda handle those things for you. So when you dig into Rust, you spend a lot of time thinking things like "wtf is a pointer?" and "wtf is a reference?" instead of actually building something useful.
That's a really frustrating part for me. I can build anything I want in PHP or Python or Java. I know those languages like the back of my hand, and if you give me a problem, I can solve it.
But then I start with a language like Rust, which concerns itself with all kinds of things I've only vaguely heard of, and then I'm completely lost. Super, super, super frustrating. It's a struggle to do a basic blackjack game -- something I could do in my sleep with Python!
So you don't know these concepts, which is already frustrating, and then you go into chat and you say "WTF is a pointer?" and hopefully people say "Oh, dude, it's so easy, imagine. you have this..." instead of "That's basic computer science, man. RTFM."
To be fair, I think Rust's documentation back at 0.9 was great. I'm positive it's way better now. But back at 0.9, it didn't answer the questions I had, which is why I had to go to chat in the first place.
But yes, most people were very, very helpful and I really did learn a lot. :)
http://books.cat-v.org/computer-science/c-programming-langua...
See chapter 5. Starts with a nice little picture.
Of course, the basic concept of a pointer is not really that tricky. It's how to use them, what you can do with them, and how to avoid accidentally shooting off your foot with them that are the tricky parts.
Anyhow, if you know any other programmers who want to understand pointers, I don't think you can go too far wrong pointing them towards Kernighan and Ritchie.
I scanned the first couple of pages again in the PDF, and still like the simplicity of the presentation, avoiding indirect metaphors ("a pointer is kind of like...").
I never got a copy of Lions, unfortunately. Seems a shame to not have more books in that style.
I can remember struggling to really learn pointers in C, the key for me was this bit of samizdat: https://en.wikipedia.org/wiki/Lions%27_Commentary_on_UNIX_6t...
So one obvious solution is to annotate a body of real code ... but in general you're suffering from trying to learn a moving target, and good documentation tends to trail....
That Version 6 UNIX(TM) was updated/reimplemented as Xv6 https://en.wikipedia.org/wiki/Xv6 ... maybe someone should do a pedagogical Rust version??? Maybe x86_64 and/or ARM?
Not hinted at you, just a general rant, as I see this a lot around me.
Actually I think the way pointers are used in Pascal/Modula line of languages it is easier to understand than how C and C++ do it.
Have a look at "Algorithms and Data Structures. Oberon version", "Object-Oriented Programming in Oberon-2." and "Project Oberon".
http://www.inr.ac.ru/~info21/ADen/
http://ssw.jku.at/Research/Books/
http://www.inf.ethz.ch/personal/wirth/ProjectOberon/
Even if Oberon(-2) isn't your cup of tea, I personally think these concepts are well explained in these books.
If you continue to be baffled in the face of consistent evidence then the problem is probably in you rather than in reality (or you're not actually baffled, but instead are feigning confusion as a way of projecting superiority). Honestly what's there to be baffled by? There are many programming environments that are both common and quite productive that have no pointers at all. I've gone literally years of my working life without touching a single pointer in production code.
That's an unusually harsh response I know, but I find this sort of attitude incredibly toxic, and it has hollowed out several communities I've been adjacent to. Some people know some things but not others. You can make them feel crappy by signalling that they are damaged or deficient, or your attitude can be positive and inviting.
But you did use references, right?
What baffles me is how many young developers code without caring about the underlying infrastructure. Not caring to understand what makes their coding possible.
I have met many that deal with programming like car owners that just want to drive down to the supermarket, so to speak.
> You can make them feel crappy by signalling that they are damaged or deficient,
I explicitly stated I wasn't targeting the OP with my comment.
> or your attitude can be positive and inviting.
That is why I pointed out a few, quite good, books where the subject of reference vs pointers happen to be described quite well in a programming language that isn't as intimidating as C or C++, while allowing for the same type of coding.
One of them even shows how to build an entire computer.
For example, I'm almost exclusively writing web applications, and have been for years (coming up on 15 years soon).
Granted, I do know a bit of C and some other more systems-y languages (and more than a little bit about the underlying implementation of Python, which is the language I prefer to use), and I even know a fair amount of underlying fundamental theory, but... ultimately my brain is of finite size and I have only finite time. So I have to prioritize like everyone else, and choose what I will spend time learning and what I will devote brain cells to remembering.
The result of this is that there are things which, to someone outside of web development, would seem horribly arcane and irrelevant, but which I have to know, and as a result there are things those other people have to know which, to me, are horribly arcane and irrelevant.
And the further result is that when I see people wading into web development from other fields of programming, I often see them make mistakes -- sometimes big, security-hole-opening, money-losing mistakes -- that are on par with someone blundering into C with no knowledge of pointers, memory management, bounds-checking, etc.
So just remember that what seems hugely important and required-learning to you may not be to someone else, and that something which seems irrelevant to you may be hugely important required learning to them :)
"What baffles me is how many young developers code without caring about the underlying infrastructure. Not caring to understand what makes their coding possible."
Our industry has many layers of abstraction, and there's always something to be gained by exploring more of the space (e.g. application domain, high level language, low level language, compiler, compiler IR, assembly, process, os, hardware apis, hardware implementation, electrical engineering, theoretical physics). However it is destructive to the social dynamics of a community when members scoff at or impugn the motives of those who do not know what they do. Both sides probably know things that the other doesn't too, why not learn from one another?
If instead of being content with being baffled with these colleagues of yours who are incurious about pointers, why not show them something cool that you can build with them! E.g. walk them through that elegant implementation of a hashmap in C that uses pointers to pointers from the front page of HN a couple of days ago.
You have a different background to many programmers, is it unreasonable that they don't understand/know something that you do? It certainly doesn't make them stupid and statements like "baffled that people don't understand pointers" definitely imply that they are somehow deficient.
In any case, why does everyone have to care about in inner workings of everything they use? It seems perfectly reasonable for computers and programming languages to be things that people can use without having to understand the details, like cars, microwave ovens, aeroplanes, TVs, radios, analog watches, GPS (the list goes on).
> That is why I pointed out a few, quite good, books where the subject of reference vs pointers happen to be described quite well in a programming language that isn't as intimidating as C or C++, while allowing for the same type of coding.
Pointing out books is nice, but it doesn't make up for effectively abusing people who might need them: "read this to learn more" is way more pleasant than "I can't believe people don't know this, read this to learn more".
/s Be nicer.
Yes we care, they are called references.
Use too much of them without thinking and performance goes down the drain thanks to cache misses.
This is why managed languages that care about performance have value types and padding support. Even Java is getting them.
This is a bit misleading. The vast majority of languages have pointers (languages without object identities exist - functional languages for example - but they are relatively the exception). However, those languages tend to give them other names.
What non-systems languages lack is pointer arithmetic and native notions of pointer-to-pointer (though it is always possible to simulate the latter).
I agree the person you responded to showed a toxic attitude. I believe/hope that the first step to improvement for people who think they don't get pointers is for them to realize they've been working with pointers all along.
It wasn't clear to me how harsh that sounds in English.
There might be a difference for people who are used to languages which are more consistent than Java (like: "all values are really objects"). Do people not have to know about references in languages like for example Python?
It wasn't that clear to me that the words were a bit harsh.