I know this is mostly gone at this point, but it should not. The fundamentals are essentials. I often meet people who are totally clueless how a computer work and have CS degrees.
"How can you do C, it is so old? By now, we must have invented faster languages. Computers changed so much recently". Sure... Binary is now expressed with emoji.
> you will always have [...]
> memory, storage
First, making a distinction between memory and storage is not an "at all times, in all places" kind of thing. It's more "this is what we do now, in the past, on some systems, it was different, and it may be different in the future" kind of thing. Single-level storage is not currently popular, but it was in the past and may yet come back. It already has, in some limited contexts.
Second, we've already seen home system storage go from paper tape to magnetic tape to magnetic disk to metallic magnetic disk to solid-state NAND Flash or close equivalent. Each has vastly different performance characteristics and details in every detail.
> human interfaces
I'm sure there are some iron-clad universals in HID. I don't know which of those translate from CLIs to touch-screens to gestural interfaces to speech recognition to pupil tracking to...
> power management, booting
Two things which have changed quite a bit even in the lifetime of "vaguely IBM PC-derived" desktop computers, and even moreso if you widen your scope up and down the power curve to include handheld systems and, you know, Real Computers What Do Real Work.
Yes, but the point is that there will always be a requirement to manage and persist the data you are working on somehow, and how you go about this somehow dramatically impacts (or should impact) the choices you make at the more abstract level of data structures. It is a fundamental concept that you will be forced to consider in one way or the other. You can have the fastest algo in the world crunching huge amounts of data, but if you then take an inordinate amount of time to store and retrieve results, it's as bad as having blazing-fast storage and crappy algos.
> I'm sure there are some iron-clad universals in HID
I agree that is traditionally considered a subclass of I/O, but I think in recent years we have seen that it's much more important than previously understood. Good software with mediocre UI is ignored while mediocre software with good UI can change the world. This is one of the few real discoveries in our field since the '80s.
>> power management, booting
> Two things which have changed quite a bit
... but are still there in some shape or form, and will forever be there. They are changing the world because people put effort and thought into them as fundamental parts of computing experiences, not one-offs that can be simply ignored as "constant time".
All that to say that sometime, having real industry veterans as teachers really influence the teaching point of view.
Don't get me wrong, I certainly think that functional programming has its place in the world, but as a first year uni student all fired up about finally learning "real" programming after years of teaching myself (back before the internet laid everything out on a platter), I was not impressed.
I don't think functional paradigms can really be appreciated by 1st/2nd year undergrads. At that age you are fundamentally impatient to make your mark in a practical sense, your approach will be instinctively imperative. You have to hit the wall (scaling / parallelism / thread management / complexity etc) before you start to really appreciate the upsides of functional paradigms.
Unfortunately, a lot of professors are actually terrible educators (after all, they did not get there by teaching but by researching) and think the learning process is as linear as house-building: "place bricks here and there so that your next row will be this way and that way". They also think people should enjoy programming for programming's sake, whereas a lot of people are motivated by a creative process driven by outcomes.