And they were right. People used in interpreted and GC ones lost most if not all the ability to reason about the system, cache, and memory.
Today's bloated "1GB RAM for a small form app" apps are the results of this.
>You don't need to "keep practicing" in order to maintain your understanding.
You 100% need to.
It's not that they lost it, but rather that they never learned it.
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.
In the snow.
Uphill.
Both ways.
What if I told you the "best engineers" pretty much all know the same things? The tools they use at work and the code they write to get paid doesn't reflect even half of what they know.
There will always be situations where a problem goes deep enough to leverage experiences from outside of the usual work role.
What if I told you that your "specialists", AI or not, are going to be objectively far worse at actually getting things done because they don't have the bigger picture in mind?
We've seen this race to the bottom in other disciplines before. Software is so special and lucky that all you have to do to prevent this is not use AI while lying to your boss that you are. When the boss finds out, they stop paying for AI and everyone is happy again.
I'd say that you need to provide some evidence for this extraordinary claim.
> What if I told you that your "specialists", AI or not, are going to be objectively far worse at actually getting things done because they don't have the bigger picture in mind?
I'd say that you need to provide some evidence for this extraordinary claim.
> We've seen this race to the bottom in other disciplines before.
Such as?
Anyone who chose to specialize went the vocational route of getting certifications and playing the contractor game. They have never truly handled anything on fire. They never stick around long enough to, and that's the whole point for them.
This pattern already happened in the (blue collar) "trades". It started in the late 20th century. Now we have some of the worst built homes, buildings, roads, etc. People will (sort of) put up with a pothole or leaky roof. They will not put up with major infrastructure outages or showstopper bugs that directly impact their minute-to-minute ability to function in modern society.
Do we really want to make this even worse with automated AI copypasta pretending to be "engineering"? Nobody is fooled. The cost cutting is hitting rock bottom, and tons of people overexposed to AI in their investments are about to lose their shirts.
Your "proof" is all there for anyone to find. Ask anyone outside your bubble.
They also started before that era, and after. I've met plenty of them throughout my career, and still do every so often. They were never very common.
> They wore all the hats
This isn't unique to that era.
> In that era, the devs at a startup were the "everything people".
They still are. You do everything because you don't have the resources to hire for any positions.
> Anyone who chose to specialize went the vocational route of getting certifications and playing the contractor game.
That depends on your definition of "specialize". I'm using it in the sense of learning one particular aspect well (in addition to anything else you learn). Certifications and contracting have nothing to do with it.
> This pattern already happened in the (blue collar) "trades". It started in the late 20th century. Now we have some of the worst built homes, buildings, roads, etc.
This is certainly true in the USA, although I'd argue that it's the companies cutting costs (and corners) rather than the tradespeople becoming unskilled. In most first world countries there are standards and audits that keep companies (mostly) in line so that you don't get disasters-in-waiting like the new Bay Bridge.
> Do we really want to make this even worse with automated AI copypasta pretending to be "engineering"? Nobody is fooled.
Like with any force multiplier tool, you get the early days where every Joe is pumping out crap (same kind of thing happened with COBOL), and then the shake-out happens where companies realize that it's not a free lunch, and you need skilled people after all.
Which reminds me of when we were admonished to continue using assembly, lest our "real" skills atrophy from too much cushy C development.
Which reminds me of when we were admonished to keep our scope and probe skills sharp, and read and understand the schematics of whatever computer we were on, lest we forget how to diagnose faults in its components.
Which reminds me of when we were admonished to practice calculating in our heads and keeping slide rule skills sharp, lest they atrophy to a calculator.
You don't need to "keep practicing" in order to maintain your understanding.
The best engineers know how our systems work down to more levels, but for average developers producing average software with average impact, average output is acceptable.