Comment by citizenpaul

> This is why any EE/ECE grads are much better developers than CS grads, because once you understand fundamentals

This is largely not the case in my experience. They probably understand the lower level details of manipulating memory better, but there's a lot more to developing software than understanding that memory is a specific place.

Springer press has a book "Programming for Engineers and Scientists" or something like that, which is the first book I picked up to "self teach CS". From the get go pointers are involved and explained in this linear memory model and explained how they work on the stack and what not. I always thought this was the best approach; the reality is taught first, the abstraction (syntax) second. Not sure why so many programming books do it the other way.

> The issue with pointers is that CS gets taught in a VERY bad way. The way it should be taught is starting with basic assembly on a microprocessor. This trains your brain to think of memory locations and data in memory.

Can't agree with this enough. The moment i finally understood what pointers are was when I landed embedded job and during debugging session I looked at memory browser that showed my variable at exact address in memory. After that all about pointer arithmetic and even function pointers became clear as day. Something at least 3 teachers weren't able to explain clear enough.

The book "Understanding and Using C Pointers: Core Techniques for Memory Management" by Richard M Reese, is a great way to learn pointers

> This is why any EE/ECE grads are much better developers than CS grads, because once you understand fundamentals

Hah, like fuck they are. The worst code I regularly have to review is written by EE grads. They have less of an understanding of pointers than the people in the office with a CS background.

Hmm. Perhaps I've just never encountered a hairy enough situation with them? That's what the eternal thought tracker notepad on my desk is for though. Maybe people are trying to do it all in their head? Pen and paper are too old school for the cool new 1000x devs?

I still feel like this argument could be transferred to nearly any concept in CS though. Abstract enough anywhere and you will always start exceeding the brains working memory.

I think it would help a lot if pointers were taught to people from the perspective of how they actually occupy memory, and what the value it stores in memory represents, and then how that value is an address that is followed when a pointer is "dereferenced", etc.

It seems a lot of people assume that pointers don't actually consume any memory and then get confused trying to understand it that way.

Pointers make perfect sense.

Now dependency injection, that's some magical bullshit right there.

> I still don't understand this decision.

Variable declaration `T v;` means "declare `v` such that expression `v` has type `T`". Variable declaration `T *p` means declare `p` such that the expression `*p` has type `T`". etc.

> asterisk is inexplicably used both to declare a pointer and a COMPLETELY different operation of dereferencing a pointer.

This is the most confusing concept of pointers. I feel this could have been easily avoided with different character like ~ or ^ or other.

Yeah, it's one thing to understand "a pointer is a location in memory". It's a completely different things to understand what to do with that information.

When I first started learning to program, it was in C, with one of those "Sam's Learn Yerself a C++ in Eleventy-Three Days" books. I was, like, 15 or something. This was long enough ago and my family was just barely poor enough that we didn't even have the Internet yet.

The book explained memory. That was not hard to understand. But we had been using stack-allocated variables through several chapters in the book so far. I didn't get why you would ever want anything as a pointer. If I wanted to write a program to add 3 and 5, why wouldn't I just say "int x = 3;"? Why bother with this stupid dereferencing syntax? Given that the author chose to explain pointers by first explain the address-of operator on stack allocated variables, it felt particularly perverse. The regular, ol' variables were right there! Why but just use them

I didn't have a concept yet of what one could even do with programming. Hell, just a few years prior to that point, I was pretty sure all of the other programs on my computer were written by massive teams of wizards manually typing out 1s and 0s.

I still managed to bungle on and write code. But my programs in C never really worked well. Though, they still worked better than my classmates' versions! Then, in my 2nd year of college, I had transferred universities and the new place taught in a Java.

Java was disgusting. It was so verbose. Why did we need all these weird, multi-sylabic, period-infested function calls to do anything? Why was it so slow? Why couldn't I write ASCII-art graphics with it? Why couldn't I run my programs on my friend's computer?

It wasn't until I had taken computer architecture that I gained a much better understanding of what any of all these computer things were meant to do. I ended up implementing a basic scripting language in Java. And then, suddenly, I understood pointers.

Think of it as types. All of the following are the same thing (declare p as an int* type). It's important for the end :

  int * p;
  int *p;
  int* p;

Now remember that the type is a memory address. I'm sure it is semantically wrong for whatever reason somebody will explain but it helps to think about it. So you can do :

  int my_number = 6;
  int* p = &my_number;

Both sides of the "=" are the same type (int* is an address, and &my_number is also an address, the one of my_number).

Now p is a pointer (or an int* or an address), and *p is... an int ! So this is totally valid :

  printf("%d\n", *p)

and for anything else than int you need to malloc that so you will see a lot of :

  my_struct* s = malloc(sizeof(my_struct);

which makes sense because malloc returns an address (the beginning address of the content of s ; yet again somebody will tell me I'm wrong to call it "the content of s" so sorry for that).

  my_struct* // is the type of s, it is an address
  my_struct // is the type of *s (some custom type of size sizeof(my_struct))

*pointer = what pointer points to &thing = address of thing

C gibberish to English gave me a chuckle thanks.

My favorite is pointers to functions passed as args for things like supplying a comparator. With more opaque void* args for customizing things even further.

I started in networking so there were a lot of memory/bit-logic/binary concepts piled on early maybe that is the case.