Hacker News Reader

Comment by lelanthran | Hacker News Reader

> Are pointers really that hard for so many people to understand?

Apparently they are; I believe it's the indirection that gets people.

Most learners aren't really taught basics properly - they learn that a variable "contains" a value, when instead they should learn that all values have a type, and some variables hold values.

> I'm not trying to brag it took me I think like 15 minutes to grok them from learning about them the first time.

I can't remember not knowing pointers, so I can't really tell you how long it took for it to click, but I do know that I had done a non-trivial amount of assembly before I used C, so maybe that helped/.

View on HN

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.

Strong agreement.

I came at C after doing 6502 and 8086 assembler. Pointers just made sense because working with indirect addressing and understanding how things were stored in memory already made sense.

The way a lot of teachers teach it is plain trash. I was raking terrible grades in OCaml and C before a student showed me what I needed to know in 15 minutes, and then I would kill it in the remaining exams. Same thing happened to my 68000 course. It didn't happen with every teacher but still, some people really need to get some better pedagogy.

The running joke is that we assume that if you know something you can teach it which goes against everything academia believes in.

> The running joke is that we assume that if you know something you can teach it which goes against everything academia believes in.

What does academia believe, then? I don't know what the negation of "If you know something you can teach it" is.

That if you don't know something, then you can't teach it?

That if you know something you can't teach it?

That if you don't know something you can teach it?

I assume the pun is that education is a discipline like any other. Asking questions, gathering evidence, testing hypotheses, publishing, lecturing etc. Not to discredit people who are naturally fantastic at figuring things out along the way. It just isn't the systemic approach academia believes in.

!(a => b) == (!b => !a), thus "If you can't teach it, you don't know something.". :-)

It's obviously "If you don't know something, you can't teach it."

Pointers make perfect sense.

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

If you have a class whose constructor depends on an instance of something else, you can instantiate that first and pass it on.

That's all there's to it.

You can do DI in your own startup code and have some logic in there that substitutes mocks when running under test. Or you could change the logging when debug is enabled. Hardly rocket science. If you can write code, you can write the startup code.

If your team likes patterns, dont mention dependency injection unless you're confident it wont get replaced with the framework of the day.

See https://www.jamesshore.com/v2/blog/2023/the-problem-with-dep...

Frameworks turn your DI code into highly complicated configuration. The end result is a giant lump of code whose only achievement is hiding the new operator and possibly also someones job security.

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

I see you there! Joking aside, for me, I also struggled a lot with DI when I first saw it in Java. The ridiculous frameworks that hid all of the details drove me crazy. Even Google Guice was supposed to be more clear, but it was never as clear as... Eventually, I settled on hand-writing the wiring in one giant 1,000+ line function that builds the entire object graph on start-up. Then I could really understand DI because you could actually read (and debug) the code doing the "wiring" (building the object graph).

Reply on news.ycombinator.com