> some of the low-level stuff (pointers, memory layouts, stuff...) really ought to be part of CompSci 101. This is forever a balance between the universal cons

> some of the low-level stuff (pointers, memory layouts, stuff...) really ought to be part of CompSci 101. This is forever a balance between the universal constants of the low-level world, and stuff which seems to be a constant but it actually a flavor-of-the-month and will be obsolete by the time you're in a position to apply it. For example, someone taking an architecture course (learn assembly language from the transistor up!) will likely learn on the MIPS, because it's a simple design which fits a simple five-stage pipeline model very cleanly and it has a simple, easy-to-teach machine code ISA as well. Plus, of course, Hennessy and Patterson teach MIPS, so you get to use their well-written book if you do, too. However, spending your time learning how to schedule opcodes to take advantage of a branch delay slot, which is an intrinsic part of the MIPS worldview, is a mistake. No architecture in modern use has them: ARM, PowerPC, and even the venerable Alpha found a way to avoid the concept, and, of course, the x86 has never had them. Branch delay slots are a flavor of the month from decades ago; they're downright archaic today. (DSPs seem to have them. Will they have them a couple generations from now? Are you actually going to learn enough about the other unique features of DSPs to make learning about branch delay slots worthwhile?) OTOH, teaching the theoretical side is a lot closer to being future-proof: Even if certain algorithms get finessed by differences in future hardware design, learning to think rigorously is always a useful pursuit.