Comment by commandlinefan | Hacker News Reader

Comment by commandlinefan | Hacker News Reader

Parent Full thread

> Every generation of programmers typically only has a certain window of knowledge

That's true, of course, but I think the disconnect he's pointing out is: a) deeper than that and b) new. I grew up a ways before he did and my first serious computer was a commodore 64. Like his 286, there was nothing you could do with it _except_ program it, and programming was hyper accessible. I immediately understood C's pointer syntax when I first came across it because the only way to show graphics on a C64 is to write to a specific memory address and the only way to intercept keypresses is to read from one.

Fast forward to the 21st century. My son is a smart kid - graduated valedictorian of a competitive high school - but he grew up with "computers" that hid the programming interface down so far that most of his experience with actual programming has been through emulators so the whole thing feels (and is!) artificial. He still struggles differentiating between what's "real" and what's emulated and I can tell from interacting with other programmers his age that he's not alone.

The GP's point is more general and stands. Technologists inevitably start off "in the middle" of a stack of technologies, and then choose to dig down and/or build up from there. It is inevitable that newcomers will not understand the technologies upon which their current work rests. A certain fraction of those will become fascinated and drawn to understand the underpinnings of their work, for an edge, or for the love of it, or both.

This process happens more naturally over time if you grow with the technology. For example, if you started programming with HTML in 1995 you not only have ~30 years of experience, but you've also seen the changes as they occurred, and have a great deal of context about the how and why each of them happened. That kind of experience can only happen in real-time, unless some kind soul is willing to write a manual to help newcomers speed-run it. Such a manual is often called a "textbook".

Until maybe 15-ish years ago, it was common for programmers to “bottom out” on the machine code level. In other words, they came to roughly understand the whole software stack in principle down to the software-hardware interface (the CPU executing machine code). The topic of this thread is that this has (allegedly) changed, developers at large don’t go down in their understanding until they hit hardware anymore.

Okay, you might argue that in earlier decades programmers also tended to have an understanding of hardware circuit design and how a CPU and memory etc. works in terms of logical gates and clocks. But arguably there is a harder abstraction boundary between hardware and software than at any given software-software abstraction boundary.

> it was common for programmers to “bottom out” on the machine code level.

It's still this way in embedded development to some large degree.

>Until maybe 15-ish years ago, it was common for programmers to “bottom out” on the machine code level.

That was more true 30 years ago, in the age of relatively simple micro-architectures in the (relatively short) era of the disconnected personal computer. But there are several directions to "bottom out". For example going in the direction of the network, you might dig into the details of ethernet, wifi, and UDP/TCP/IP. You can even go in the direction of electronics, and understand how to de/solder components, design and fabricate PCB's, or in the direction of enclosures and mechanisms. You can go in the direction of understanding the market itself, and all the CPU/GPU/motherboard/PCI/m2/SATA/chipset combinations and how they work together. You might go in the direction of understanding systems programming and the kernel, ttys, and file descriptors, or in the direction of cryptography, etc.

Complexity is a sign of a healthy ecosystem, and we see this repeated again and again in every area of human endeavor that continues unabated for any length of time. A field starts small and understandable by one person, but quickly continues to grow until it cannot reasonably be understood by any one person. Chemistry, math, engineering, physics are like this. Is it reasonable to lament this fact and consider modern practitioners any less than earlier ones for their lack of total knowledge of it?

>Okay, you might argue that in earlier decades programmers also tended to have an understanding of hardware circuit design and how a CPU and memory etc. works in terms of logical gates and clocks

My degree included this and I'm very glad it did.

For those with past web stack exp 20-30+ yrs) 'without' modern web stack experience. How do you stand out for those job listings requiring modern stack? How do you tie those past experiences to remove such disconnect?

Hiring manager's looking for React in next role. Would you prefer to someone with lots of experience (old ways) or someone expert in React with few years.

Looking for context.

Dude/ette; pointers WRECKED people's minds (myself included) when we learned about them in CS101 (modified for computer engineers) in 2006. I don't know why either; they make so much sense.

I think the one weird trick to understand pointers is to do a tiny amount of assembly programming. Assembly is very simple and pointers are everywhere. Writing useful programs in it is a chore, but you don't need to!

I never understood the struggle people have with pointers, to me they are quite obvious, unless I'm missing some important thing about them. You have something you need to store; it's stored in memory; so you need to store its address if you intend on accessing it; so you store it in a pointer. From there, the rest comes logically.

I think the problem with C (well my problem) was the *& characters all over the place. I think because I spent too much time with pascal where (in my opinion) the pointer syntax is more symmetric.

Can you explain why?

I heard about this, and avoided pointers for a long time because of a fear that comments like yours gave me.

I then ended up realizing Java objects that I had been dealing with were just memory references, and that led me to learning about pointers in C.

Once I realized that I basically already knew what pointers were, I was pretty confused about why it created so much difficulty. Like it was an actual barrier for me to really understand how simple they are, so few moving parts.

It seems to me that everyone intuitively understands the difference between a home address, and the home itself.

Not to say that I'm an expert in pointer arithmetic or anything, I still prefer symbolic programming to dealing with pointers directly, for the same reason I prefer spoken English to Morse code.

Because C syntax makes pointers harder to use and understand than they really are. Also constraints around pointers, casting etc. I still clearly remember figthing the C compiler and getting back "makes integer from pointer without a cast" complilation errors and segfaults. That's the main reason why I don't want to touch C or Rust again. D felt so much easier. I could finally write a program without endlessly fighting the compiler.

I've never programmed in D. I only here good things

I definitely agree that stuff is pretty annoying.

I guess I've gotten used to it to the casting behavior. Though these days I program mostly in dynamically typed languages.

If I recall correctly, the big gripe about them at the time was understanding all of the situations in which pointers can be used outside of simply accessing data, like setting one pointer to another one and doing pointer math with char-arrays (i.e. setting one variable's memory address to another). Like another poster said, much of this is unique to C and C++ without smart pointers.

Reply on news.ycombinator.com