Degrees are useful but there's a whole class of things they skip over as well. When I was going to college the state college didn't teach C on a regular basis and we usually had a number of people at my community college since the course was offered there. When I was looking to transfer from community college into state not a single college offered C++(it was during peak Java) and so I didn't attend.
Even then I regularly find that so-called "fundamentals" are missing, the number of times I've had to explain page tables, how the kernel shares memory and other core details is surprising. Everyone drives Big-O notation left/right/center but can't tell what a page fault is or why algorithms with higher complexity wipe the floor with better "ideal" algorithms under actual operating constraints. I've found that engineers who have drive or innate curiosity will poke in those areas but getting a degree doesn't automatically confer that knowledge(or guarantee that it sticks).
Also, if you're getting into systems programming I care about 0% about "prestige", it's a domain that is even more binary(things work or they blow up spectacularly[1]) than some other programming domains. I care that someone understands the fundamentals, can apply reasoning and drive a hypothesis with data more than what college they did/didn't attend.
And those colleges were right. You shouldn’t have a class that teaches C, C++, or Java. You Should have classes that teach embedded programming, operating systems, object oriented programming, and algorithms.
> When I was looking to transfer from community college into state not a single college offered C++(it was during peak Java) and so I didn't attend.
Why is C / C++ education so important?
Personally, What helped my during my studies were type theory, PL, complexity theory, etc. Had I gone into systems development, then my compiler courses would probably be of most value (which are standard curriculum in any CS degree).
If you don't understand C, C++, or one could argue Rust these days you're sitting at an abstraction level much higher than where the "systems" domain tends to be. ABI, cache misses, page tables and memory mapping, restrict, all of that stuff is at an arm's length in a managed language.
One of the best courses I had was taught by Bruce Dawson, it was an entry-level "image processing" course but really it was a tour-de-force on cache hierarchies, modern computer architecture and how to build efficient real-world algorithms and not things that just scored well on the complexity scale. The first assignment was a simple bit-blit, he grabbed a random assignment from the class and in about ~30 minutes walked us through a multi-order-of-magnitude performance improvement with just small adjustments that made the program more cache-aware and also showed how you empirically test for performance improvements instead of doing it in a theoretical manner.
Back when I was in college(which was admittedly a long while back now) those sorts of things just weren't taught and that class was by-and-far an outlier from traditional coursework. My experience has been that even though there's a lot of talk about "fundamentals" in a CS degree it's touched at such a shallow layer that practical application of any of those fundamentals are missing and it doesn't "stick".
I've met all of a handful of people who can tell me what restrict does(much less how to use it), what a cache-aware data structure is or why we care about value types. ABI is just a 3-letter word to a large majority of people because they just don't have to deal with it(but are then oblivious when it blows up, I.E the number of times I've seen STL in what are supposed to be ABI-safe boundaries). That stuff is all foundational at the systems level. I've had much better luck with breaking people of their assumptions(I.E. Big-O) and working up from first-principals of how computer architecture works and structuring systems in such a way that take advantage of that instead of a theoretical ideal.
> If you don't understand C, C++, or one could argue Rust these days you're sitting at an abstraction level much higher than where the "systems" domain tends to be. ABI, cache misses, page tables and memory mapping, restrict, all of that stuff is at an arm's length in a managed language.
To me, this is a bit muddy:
Yes, when doing systems level development, you need to understand the system you are targeting. Not all CPUs have a concept of cache misses or page tables. At my uni this was taught through computer architecture and operating systems classes.
These courses incidentally also included C, though they didn't need to. The reason that did was because they were precedents for the compiler course and prepared the students to understand compilers (I TAed in said courses). Later courses at my uni would be algorithms engineering that taught students how to make, well, cache aware implementations.
Understanding how a given hardware architecture works on how to most efficiently utilise it has nothing to do with C / C++. Many courses at most (European?) universities will happily teach you everything you need to know, but C / C++ are probably not even mentioned in the teaching material.
There are always exceptions, programming for the PS3 was... interesting given the SPUs didn't have any caches, although one could argue they were closer to DSPs with the manual DMA required. I'm not really interested in arguing semantics but more that those languages tend to be what you see modern, battle-tested OSes developed in.
My point is if you're not using C/C++/Rust what are you using that exposes those concepts? Not saying you can't do those things in other languages(I've shipped cache-aware datastructures at scale in Java using ByteBuffers + flatbuffers) however you're having to reach through abstractions and/or other limitations. Say nothing that on most OSes that C tends to be the OS ABI as well.
How do those European (?) universities deal with the difference between theory and practice? I have a hard time imagining how you would understand how to "most efficiently utilize" a given architecture without writing code and trying things out.
The choice of programming language isn’t that important insomuch as Computer Science is not about coding.
Surely using Python to code OS course assignments does not make much sense. But that choice comes naturally with the course in question. Courses about a specific language are set out to become dated from the start.
Even then I regularly find that so-called "fundamentals" are missing, the number of times I've had to explain page tables, how the kernel shares memory and other core details is surprising. Everyone drives Big-O notation left/right/center but can't tell what a page fault is or why algorithms with higher complexity wipe the floor with better "ideal" algorithms under actual operating constraints. I've found that engineers who have drive or innate curiosity will poke in those areas but getting a degree doesn't automatically confer that knowledge(or guarantee that it sticks).
Also, if you're getting into systems programming I care about 0% about "prestige", it's a domain that is even more binary(things work or they blow up spectacularly[1]) than some other programming domains. I care that someone understands the fundamentals, can apply reasoning and drive a hypothesis with data more than what college they did/didn't attend.
[1] https://www.usenix.org/system/files/1311_05-08_mickens.pdf