What's worked in Computer Science: 1999 vs. 2015 (2015)

Original Article ↗ Hacker News Discussion ↗

Debating what has “worked” in computer science from 1999 to today, commenters revisit Butler Lampson’s old scorecard in light of modern realities like ARM-based Macs, RISC‑V, GPUs, and large‑scale neural networks. Many argue that RISC, “fancy” type systems, and functional programming have shifted from niche or “no” to at least “maybe,” citing Rust, TypeScript, and widespread FP-inspired features in mainstream languages. Others highlight how entrenched legacy systems (COBOL, MATLAB, x86) and practical constraints around parallelism, security capabilities, and formal methods complicate any simple verdict on which ideas truly succeeded.

Legacy and Industry-Specific Languages

  • Many critical systems depend on “old” or niche tech: Erlang (telecom), COBOL (banking), MATLAB/FORTRAN (scientific), MUMPS (healthcare).
  • Discussion asks what can be learned from why such languages succeed and stay entrenched.
  • One view: language adoption and evolution resembles spoken languages—driven by social and historical forces more than technical merit.

Fancy Type Systems and TypeScript

  • TypeScript is praised as having “realized” strong typing for the web programming majority, especially those without formal CS background.
  • Others argue similar or stronger type systems existed decades earlier; TS’s main achievement is bringing them to the largest practitioner base.
  • Debate over how “fancy” TS really is compared to Java/C#/Checker Framework:
    • Pro: structural types, unions, mapped types, rich inference, powerful libraries (e.g., type-level SQL).
    • Con: it borrows heavily from Java/C#, lacks a formal spec, and can behave in surprising ways.

Static Typing in Dynamic Languages

  • Python and JavaScript are gaining optional typing; tools and style guides are making it semi-mandatory in teams.
  • Some fear mandatory typing would betray Python’s purpose, predicting a fork or new untyped language.
  • Others say “mandatory” in practice still allows escape hatches (Any, casts), making it less painful than fully static languages.
  • Types are valued for editor support, onboarding to large codebases, and team coordination, despite added friction.

RISC, CISC, and Instruction Sets

  • Strong thread revisiting the article’s “RISC = No”:
    • Many now see ARM’s mobile dominance and Apple’s M-series as evidence RISC is a “Yes” or at least “Maybe.”
    • Counterpoint: the real divide is x86 vs non‑x86; modern ARM and x86 are both heavily micro‑op based and blur RISC/CISC lines.
  • Some emphasize ARM’s fixed-width instructions enabling very wide, efficient decode, contributing to high perf/W.
  • Others argue RISC originally mattered when gate budgets were tight; today we can afford complex ISAs plus deep pipelines.
  • RISC‑V is cited as a success mainly due to openness rather than “RISC-ness” per se, though tiny RISC‑V cores don’t even use micro‑ops.
  • Discussion dives into historical comparisons (R2000 vs 80386), pipeline vs clock speed, process nodes, and microcode, with no single consensus.

Capabilities and Security

  • “Capabilities” is clarified as capability-based security (unforgeable tokens that confer specific rights, e.g., file descriptors).
  • Mobile app permission prompts are loosely related but mostly implement semi-static, identity-based permissions, not full-blown capability systems.
  • Capabilities are seen as elegant but rarely used as the sole basis for real-world security; they appear mainly inside sandboxes and low-level OS code.

Functional Programming vs “Functional Style”

  • Many see “pure FP” as a practical “No,” but FP ideas (lambdas, pattern matching, sum types, higher-order APIs) as increasingly mainstream.
  • Viewpoint 1: Hybrid languages (Java/C#/JS with FP features) give most FP benefits while staying imperative/OO.
  • Viewpoint 2: These hybrids are suboptimal; true FP needs more than lambdas—e.g., expression orientation, immutability by default, persistent data structures, explicit effect management.
  • Ongoing debate about what defines FP:
    • Some say first-class functions suffice.
    • Others insist on stronger conditions like referential transparency and structured effect handling (monads or alternative effect systems).
  • Clarification that “records” themselves are not inherently functional; they predate OOP and exist in many paradigms.
  • Separate tangent on what makes something “object-oriented,” with no agreement; records in Java are seen by some as anti‑OO because they minimize hidden state/behavior.

Parallelism, GPUs, and Rust

  • Question whether GPUs/TPUs “count” as parallelism for the article’s classification.
    • One stance: they implement the “wizard in a box” model—parallel kernels written by experts, not general-purpose parallel programming.
    • Another: almost all GUI/web apps implicitly use GPU parallelism, plus map‑reduce and SIMD are where parallelism really works.
  • Rust is proposed as potentially changing the parallelism picture, with its ownership/borrow system giving strong thread-safety guarantees on top of memory safety.

Neural Networks and Changing Evaluations

  • Some suggest NN status would be “Yes” by 2024, noting major deep learning papers around 2014–2015.
  • Others stress that neural nets have had multiple hot phases since the 1960s; 2015 was a resurgence built on decades of prior work.

Meta: Updating “What’s Worked” for 2024

  • Several commenters want an updated table:
    • RISC shifted from “No” (2015) to at least “Maybe.”
    • Fancy type systems are more prominent (Rust, advanced TS), arguably moving from “No” to “Maybe/Yes.”
    • Functional ideas are now “expected” features in many mainstream languages.
  • There is general caution that any yes/maybe/no classification ages quickly and should not be treated as timeless truth.