>> If you're really interested in your subject you don't need people telling you what to learn and not to learn.
You at least need someone to expose you to what is available to learn. It's possible that without guidance a lot of people would never even think of going to the lower levels, they can be nearly invisible to someone working on (for instance) web apps with high level server frameworks and lots JS.
When it comes down to it, you need to know what you don't know, and some of the low-level stuff (pointers, memory layouts, stuff...) really ought to be part of CompSci 101.
Particularly in a country where pre-university computer education is inadequate or absent. Most UK CompSci folks have mathematical and science backgrounds but no formal education in computer science or programming.
This is very true, and I can attest to it from personal experience.
I grew up in Redmond Washington, in the heart of Microsoft - land, surrounded by programming and programmers. I learned a lot of the mental meta-skills that go hand in hand with programming, but I didn't ever learn to program, even though I thought it interesting and I wanted to understand it.
It was a challenge to even know what I wanted to know, and there wasn't anyone around to answer my "but how, and why?" questions to begin learning. It took till I was in college for me to start learning to program, because I had excellent professors who would answer my questions for literally hours. As well, I finally had problems that needed solving (if for no other reason than I needed to turn them in).
> 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.
You at least need someone to expose you to what is available to learn. It's possible that without guidance a lot of people would never even think of going to the lower levels, they can be nearly invisible to someone working on (for instance) web apps with high level server frameworks and lots JS.
When it comes down to it, you need to know what you don't know, and some of the low-level stuff (pointers, memory layouts, stuff...) really ought to be part of CompSci 101.
Particularly in a country where pre-university computer education is inadequate or absent. Most UK CompSci folks have mathematical and science backgrounds but no formal education in computer science or programming.