> People used in interpreted and GC ones lost most if not all the ability to reason about the system, cache, and memory.
It's not that they lost it, but rather that they never learned it. I didn't lose my ability to reason about those things during the 4 years where I worked in Python and Java.
And once again, for average software devs that's fine. Most non-critical software that doesn't perform very complex tasks can be optimized for time-to-market, which of course loses in other areas the business doesn't care as much about (such as bloat).
I get the impression that analogies like this are trying to disguise a moral judgement as a practical one.
It's clearly absurd to abandon GC languages or to require everyone who uses one to learn assembly. Yes, it could be beneficial to learn the lowest levels of the machine, but with an opportunity cost. Advocates of many such principles are often those who have already paid that opportunity cost and consequently see no downside.
There has always been a known trade off with how much you need to know about a system against the practical ability to make something that someone uses.
If we talk directly to the practicality issue, what happens when AI can rewrite a program written in a highly expressive, but inefficient, language? A future AI might be able to turn a bloated prototype into a sleek, high performance, program where every byte is justified.
Then it would be absolutely true that a programmer who did not know the low level intricacies would not know how to do that for themselves, but would they need to? If they can make the things that they want to make and those things do not have obvious limitations, they could be learning a skill more relevant to the world that they live in.
By all means, learn assembly if you think it is interesting. I have learned Asm (and indeed written assemblers) for a variety of systems. I won't hold it against someone if they spend the time figuring out cross entropy instead.
It's not that they lost it, but rather that they never learned it. I didn't lose my ability to reason about those things during the 4 years where I worked in Python and Java.
And once again, for average software devs that's fine. Most non-critical software that doesn't perform very complex tasks can be optimized for time-to-market, which of course loses in other areas the business doesn't care as much about (such as bloat).
When that's not the case, you hire a specialist.
It's clearly absurd to abandon GC languages or to require everyone who uses one to learn assembly. Yes, it could be beneficial to learn the lowest levels of the machine, but with an opportunity cost. Advocates of many such principles are often those who have already paid that opportunity cost and consequently see no downside.
There has always been a known trade off with how much you need to know about a system against the practical ability to make something that someone uses.
If we talk directly to the practicality issue, what happens when AI can rewrite a program written in a highly expressive, but inefficient, language? A future AI might be able to turn a bloated prototype into a sleek, high performance, program where every byte is justified.
Then it would be absolutely true that a programmer who did not know the low level intricacies would not know how to do that for themselves, but would they need to? If they can make the things that they want to make and those things do not have obvious limitations, they could be learning a skill more relevant to the world that they live in.
By all means, learn assembly if you think it is interesting. I have learned Asm (and indeed written assemblers) for a variety of systems. I won't hold it against someone if they spend the time figuring out cross entropy instead.