4 ms·

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

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

simpaticoder 2y ago
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".
- layer8 2y ago
  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.
  - 15155 2y ago
    > 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.
  - simpaticoder 2y ago
    >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?
  - StuffMaster 2y ago
    >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.
- jzer0cool 2y ago
  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.
nunez 2y ago
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.
- ahartmetz 2y ago
  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!
  - cafeinux 2y ago
    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.
    - mainguy 2y ago
      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.
- aeonik 2y ago
  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.

simpaticoder 2y ago

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

layer8 2y ago
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.
- 15155 2y ago
  > 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.
- simpaticoder 2y ago
  >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?
- StuffMaster 2y ago
  >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.
jzer0cool 2y ago
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.

nunez 2y ago

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.

ahartmetz 2y ago
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!
- cafeinux 2y ago
  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.
  - mainguy 2y ago
    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.
aeonik 2y ago
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.