Hacker News Reader

Comment by ActorNightly | Hacker News Reader

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.

Then when you start using pointers, it makes sense. If variable is a pointer, that means its a memory location. *variable is a way to get that data. Then arrays is just a wrapper around pointer arithmetic.

Whereas with CS, you learn about variables first, which is an abstraction on top of memory, and pointers don't make sense in this regard.

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

View on HN

> 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.

>but there's a lot more to developing software than understanding that memory is a specific place.

Yep, and all of that is derivative from how to organize memory. Classes are just more fancy structs. Object creation is memory initialization. Processing flow and code reuse is recognizing memory access patterns. ETC and so on.

All of software engineering is not derivative of memory organization. Algorithm efficiency for example is entirely independent of physical memory implementations. Just because an algorithm may use a set or an array does not make it derivative.

> Algorithm efficiency for example is entirely independent of physical memory implementations

This is wrong. Lots of algorithms behave completely differently based on memory layout. There is typically an inflection point where big O effects start coming into play, but at most scales, memory locality tends to be way more important in determining how efficiently something runs.

That's why I said algorithm efficiency and not wall-clock time or something else implying that I was talking about real-time.

If your algorithm is poorly designed and does significantly more work than necessary then that is independent of physical memory.

It's like you are trying to misunderstand me.

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.

You can do the same with regular, non-embedded programs in a debugging session

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.

I have probably like 2000 interviews under my belt across multiple companies. Your experience is an outlier. EE/ECE grads generally can write better optimized software - the only downside is that they aren't thinking as much of maintainability in design of interfaces, but thats a problem that is solved with LLMS

Reply on news.ycombinator.com