All this abstraction with garbage collection and virtual memory etc etc is only taking us further away from the hardware. In some ways its good to think like a 1975 programmer because you are acknowledging the fact that there's hardware underneath. If you completely ignore that and rely on the abstractions provided to you by an OS layer, the end result is you get a system that uses resources very wastefully. Look at how much software has bloated in the last 35 years. A large reason for that is the amount of abstraction of the hardware and lower layers of software we've started relying on. The more abstraction you use, the easier your job becomes, but it also results in a less lean system
My goodness, non-sequiturs wrapped in inconsistencies disguised by absurdity!
Virtual memory uses CPU traps to do page faults in x86 land. Abstractions are useful and in fact even if you go all the way to assembly, you've still got a thin abstraction over the hardware. If you don't have an operating system, then no software will be written. If you look at software over the last 35 years, you'll notice it has become easier to use, and it does more complex things.
The memory, hard disk and CPU speed requirement of modern day PCs has also gone up substantially. I wouldn't call them lean. That, in my opinion, is where the future lies and to get there we have to get closer to the hardware, not abstract it away further. Most CS background programmers tend to leave the details of the hardware to the OS's abstraction layers thereby isolating themselves from the hardware designs of the EEs. In the future, we need design teams that do both. That's driven by the lean requirement.
