Computer science courses that don't exist, but should (2015)

Original Article ↗ Hacker News Discussion ↗

Resource-Constrained & Historical Computing

  • Many commenters like the idea of “Classical Software Studies”: writing games or apps on 64KB-era machines (Commodore, Game Boy, PDP/VAX, etc.) to relearn discipline around memory, modularity, and system limits.
  • Others warn this can give warped intuitions for modern tradeoffs (maintainability vs. micro-optimizing for RAM/CPU). Good as an introductory or elective experience, not the core of a curriculum.

Real-World Software Engineering Skills

  • Strong support for courses on:
    • Handling shifting requirements and “moving goalposts” via realistic group projects where specs change late.
    • Version control theory and practice (branches, merges, bisect, strategies).
    • CI/CD, build systems, containers, deployment pipelines, and debugging real systems.
    • Unix/Linux fundamentals (shell, text tools, processes), basic sysadmin/networking.
    • Teamwork, project management, and client communication.
  • Some report such courses exist in pockets (e.g., sneaky spec changes, devops-focused Java courses), but they’re rare and hard to fit into standard curricula.

CI/CD, DevOps, and What Counts as “Computer Science”

  • One side: CI/CD, Kubernetes, Jenkins, etc. are “not CS” but tooling; curriculum should focus on theory.
  • Other side: there’s plenty of CS in these topics (distributed systems via k8s, algorithms/policies in merging, conflict resolution, scheduling) and they are central to modern practice.
  • Practical obstacle: teaching CI/CD often devolves into teaching specific vendor stacks, and students may lack prerequisite skills (shell, Git, Linux).

History of Computing & “Classical Software Studies”

  • Many argue computing should treat its history more like physics or civil engineering: understanding past systems (VisiCalc, MacPaint, early hypermedia, Smalltalk-like systems) prevents constant reinvention and can inspire better designs.
  • Pushback: computing’s history is short and deeply tied to changing hardware “substrate,” so 1970s constraints may not generalize to today.
  • Counter-pushback: for most everyday applications, hardware stopped being the limiting factor decades ago, so historical software and interaction ideas are still highly relevant.

Object-Oriented vs Functional Programming / “Unlearning OOP”

  • The proposed “Unlearning OOP” course triggers heated debate:
    • Critics: this reflects a shallow or strawman view of OOP; many large systems rely on it successfully, especially in enterprise environments.
    • Supporters: OOP as commonly practiced (especially mutation-heavy, inheritance-centric designs) creates tightly coupled “webs of state” that resist refactoring, whereas functional styles encourage small, composable, testable units.
  • Several note that OOP and FP are often complementary in practice (e.g., functional core, imperative shell), and that the real goal is to loosen the dogma that “everything must be an object.”

Performance, “Slow Languages”, and Algorithmic Complexity

  • Enthusiasm for a “Writing Fast Code in Slow Languages” course:
    • Show that algorithmic improvements (O(N) vs O(N²)) often dominate language speed.
    • Teach vectorization, leveraging C-backed libraries (NumPy, Python sort), and architecture-aware design.
  • Some argue Big-O ignores constants and hardware effects; in practice, “worse” algorithms on linear, vectorizable data can beat “better” algorithms on pointer-heavy structures.

Debugging, Legacy Code & Software Archaeology

  • Many want explicit training in:
    • Systematic debugging (beyond print statements): debuggers, logs, profilers, memory tools; avoiding “debugging hypnosis.”
    • Reading and modifying large, messy, or abandoned codebases; understanding tickets, wikis, version history, and “digital archaeology.”
  • Suggestions include courses modeled on labs: given a legacy system with many bugs/perf issues; course ends when tests pass and scaling goals are met.

Programmer Psychology & Workplace Dynamics

  • Popular proposed courses:
    • “Refusal Lab” and ethics labs: practicing saying no to unethical or impossible demands.
    • “Obsessions of the Programmer Mind”: code formatting, type wars, over-refactoring, novelty-driven development, hype-chasing vs. principled skepticism.
    • Team dynamics, meeting behavior, blame management, and career realities (cheating analogies, “success has many parents; failure is an orphan”).

Broader Curriculum & CS vs Software Engineering

  • Recurrent theme: many of the proposed classes are really software engineering, devops, or professional practice, not “computer science” in the narrow theoretical sense.
  • Some fear CS degrees are drifting into coding bootcamps; others argue current programs already overemphasize theory and underprepare students for actual software development.
  • Shared undercurrent: whatever the division, students benefit from exposure to multiple paradigms (imperative, OO, functional, logic), historical systems, and at least one deep dive into how real software is built and maintained.