Software Rot

Original Article ↗ Hacker News Discussion ↗

Choosing technologies for longevity

  • Many participants deliberately choose “Lindy”/long-lived tech subsets: ASCII text, SQLite, POSIX shell, Perl, PHP, HTML/JS/CSS, sometimes Lua, CGI, Win32.
  • Others push back that this can be dogmatic and sacrifices ergonomics; they argue it’s a tradeoff versus time wasted constantly learning and chasing new stacks.
  • Some view “boring” or “understood” tech as a positive signal; others note that popularity often accelerates rot because popular ecosystems change faster.

Languages, runtimes, and ecosystems

  • Perl, POSIX shell, TCL/Tk, COBOL, Emacs Lisp, and SQLite are repeatedly cited as unusually stable over decades.
  • Python is contentious: some report decade-old scripts still running fine; others cite 2→3 breakage, packaging churn, and recent 3.12/3.13 changes as disqualifying for 20-year horizons.
  • PHP’s recent willingness to break compatibility is called out as a growing maintenance burden.
  • JavaScript in browsers is praised for extreme backward compatibility, but people distinguish:
    • Runtime-level stability (old bundles keep running).
    • Tooling/package-level rot (npm, bundlers, React, etc.) which often breaks in just a few years.

Dependencies, packaging, and “dependency hell”

  • There’s broad agreement that rot often comes from dependencies, not core runtimes.
  • Participants describe:
    • Python virtualenv/packaging churn.
    • JS “npm hell”.
    • Linux shared-library and distro version churn vs. static-binary approaches.
  • Several emphasize ruthless dependency minimization and selecting libraries/authors with a strong compatibility record.

Platforms and OS stability

  • Windows/Win32, .NET, VBA, Java JVMs, IBM mainframes, and AS/400 are highlighted as “marine-grade” for long-term compatibility.
  • Linux sparks disagreement:
    • Kernel syscall interface is considered stable (“don’t break userspace”).
    • In practice, userland libraries, GUIs (GTK), and distros often break old binaries or require recompilation.
  • Containers, VMs, and emulators are seen as solving “can it still run?” but not “can it still interoperate securely with modern networks, protocols, and formats?”

Broader causes and strategies

  • Rot also comes from changing requirements, business rules, regulations, and protocols, not just tech.
  • Some argue most business software is now in constant repair due to agile-style “value per sprint” and unstable APIs.
  • Proposed mitigations:
    • Design “bedrock platforms” and offline-capable systems.
    • Favor stable specs (POSIX, Win32, SQLite LTS promise).
    • Invest in tests, monitoring, and black-box checks to detect drift.
    • Accept that some software should be cheap and disposable, while a smaller core should be engineered to last.