Comment by lelanthran
4 days ago
> 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/.
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.
4 replies →
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.
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).