Computer Science Courses that Don't Exist, But Should (2015)
29 points by runxiyu
29 points by runxiyu
I don't think the link is great, but "classical Software Studies" brings me to one of my obsessions: that computing practitioners we do not have "self-awareness" about our discipline.
Some time ago, I was at the doctors being attended by a nurse. This nurse was tutoring another nurse, in what looked like a well-structured apprenticeship; they would describe what they were doing to me and why, that kind of thing.
I feel other disciplines are more "self aware"- likely by virtue of being older and more evolved, and as part of the teaching of the discipline, things such as studying the history of the discipline, teaching didactics of the discipline, and others are included. When I studied in University ("computer engineering"), I really missed a lot of that. It also makes me very bitter than in recent years, many have made a huge effort to make LLMs more effective in our discipline- often by writing comprehensive documentation and providing automation... which we often refuse to provide to junior colleagues.
Our discipline is young, and we haven't figured out a lot of it! This manifests in a lot of places- teaching our discipline seems worse than other disciplines, software project failure rates are concerning, we still do a lot of things we should automate away, etc. Ironically, I feel we're often too focused on our immediate problems and... maybe we should navel-gaze more?
The same is true for software design in general imo. At least in my education, there was no concept of "the paths not taken" or how completely different approaches could be used for the same problem, with different pros and cons. It's then difficult to make great design decisions later on, because of lack of experience or guiding principles. I could say the same for testing; I wasn't exposed to great ways to test either. Anytime you start discussing those topics, I find that people rely a lot on heuristics and personal experience, just like when you ask what is "great code".
It's frustrating because you'd expect that a discipline built on engineering/science would also create a body of knowledge about the process of writing, growing and maintaining code. I don't think the cookie-cutter approach of "design patterns" is sufficient either because going over a bunch of patterns doesn't improve the "hard part" of finding design pressures and possible solutions, just like knowing a lot of ways to sort an array doesn't help with problem solving.
From a to-be-published interview:
sometimes I try to fix the bug to figure it out: Why does some change fix the bug? Then go over it that way. The fix may not be the correct fix yet.
I think I'm missing context to fully understand, can you expand on what you mean?
For an actual "course" that addresses the lack of Unix education for undergrads, I enjoyed MIT's Missing semester.
I'd sign up for most of these, but this one:
CSCI 4020: Writing Fast Code in Slow Languages Analyze performance at a high level, writing interpreted Python that matches or beats typical C++ code while being less fragile and more fun to work with.
raised an eyebrow. Usually when I see "python implementation in N times faster than C implementation" comes down to a wholly different algorithm implemented in the HLL, or some HLL nicety like automatic I/O buffering, or something else that makes the whole thing an apples and oranges comparison. If you look at high performance python libs most of them come down the C interop or some other delegation to something low level.
CSCI 2170: User Experience of Command Line Tools An introduction to UX principles as applied to command line programs designed as class projects. Core focus is on output relevance, readability, and minimization. UNIX "ls" tool is a case study in excessive command line switches.
Hah, this would be a good one. "CLI design sensibilities" is one of those things that, in my experience, is a good proxy for someone being a really solid developer and yet I can see no real reason why this would be the case.
Usually when I see "python implementation in N times faster than C implementation" comes down to a wholly different algorithm implemented in the HLL, or some HLL nicety like automatic I/O buffering, or something else that makes the whole thing an apples and oranges comparison.
Here's the thing though: a lot of the time, stuff is fast in C/C++ not just because it's "close to the metal." But stuff in any given implementation's standard library is very heavily optimized. e.g. trigonometric functions are probably using lookup tables and not calling out to assembly, as I learned in undergrad. Don't forget compiler optimization tricks, either. I think it's a very fair comparison and is, in fact, the point of the exercise.
I don't think "CSCI 4020" could be an entire class though, but something that could be learned as a project in a data structures/algorithms class.
as I learned in undergrad
Oops too late to edit, but meant to link to my specific comment here: https://lobste.rs/s/hnp82i/ruby_might_be_faster_than_you_think#c_zh7ezk
Includes detailed study of knee-jerk criticism when exposed to unfamiliar systems.
I feel like this is one of the undercurrents of liberal arts education writ large. From observations in industry we do need this class but in theory we shouldn't if CS is embedded in a liberal arts curriculum. Unfortunately in the U.S. the high cost of college tuition can make it feel risky to get a broad education instead of hyper-focusing on a major.
Love it.
CSCI 2100: Unlearning Object-Oriented Programming
For me, Execution in the Kingdom of Nouns was that class!
I am taking a course called “Contribution to open source software” next semester, and as much as i feel like its going to be a cake walk, its good that my university teaches and encourages this to people newer to software engineering
I very much emphasize with "CSCI 3300: Classical Software Studies". Can't say I am qualified to propose anything concrete, but I love learning about past systems! It makes me feel much more grounded in my practice and open to different perspectives to approach the field. It is in a way for me a pocket bubble for when the breakneck speed at which some people drive the industry gets too soul crushing.