[subwindow]

I don't think that knowledge of low-level systems programming is ever going away. The order in which we learn it is merely changing. In the past, everyone had to understand the absolute basics first because the higher level abstractions were very leaky. Over time the abstractions have gotten better, performance has become less of a problem for most cases, and low-level systems are no longer something everybody needs to know in order to get by at the higher layers of abstraction.

However, that doesn't mean that people aren't learning it anymore. They're just starting with a broad set of high-level knowledge and drilling down into the parts that are important to them. For instance, recently I've been toying with compact string representations of big integers (using bit shifting: how topical).

The end result is that you end up with developers who have broad knowledge of the higher layers of abstraction but incomplete and specialized knowledge of the lower layers. That seems perfect to me.

[ajross]

The knowledge can't go away, because someone needs to write the systems: sure apps might move to managed/interpreted environments exclusively, but those interpreters and language runtimes need to be written first. And they run on a kernel, with drivers for hardware that needs firmware.

I don't lose much sleep at night worrying about my job security as a "systems" programmer. If anything, my skill set is becoming underrepresented and hard to staff.

[ZephyrP]

They just can't write LKMs like they used to.

[pheon]

the order we learn is only a function of the constraints of the type of problems/projects we choose.

.. yet it is sad when a freshly minted CS grad thinks bit shifting and multiplication have nothing in common.