Enlightenmentware

Original Article ↗ Hacker News Discussion ↗

Certain tools go beyond solving a problem and fundamentally change how people think about software, inspiring the term “enlightenmentware.” Commenters highlight examples ranging from Emacs, Git, Nix/NixOS, Docker, build systems like Bazel and Buck2, and languages or environments such as Smalltalk, Haskell, and Common Lisp, explaining how they reshape ideas about composability, reproducibility, interactivity, and developer tooling. Alongside this enthusiasm runs a recurring tension: many of these systems are extraordinarily powerful but also complex and opaque, raising questions about how to make such transformative software more approachable without losing its depth.

Overall theme: “Enlightenmentware”

  • Tools that reshape how you think: not just useful, but conceptually transformative.
  • Many examples are “deep but small” systems: simple cores with large expressive power.
  • Several commenters note that such tools often feel hard at first, then become fun and “world‑reframing.”

Build systems, package managers & reproducibility

  • Bazel/blaze is praised for rock‑solid, explicit dependency DAGs, fast incremental builds, and making complex builds tractable.
  • Strong criticism too: steep conceptual spike (plan/execute, transitions, rules), invites spaghetti macros, tooling/docs feel underbaked compared to the power.
  • Nix is repeatedly proposed as an alternative/complement: treat it as a composable build tool and distribution rather than just a “package manager.”
  • Debate over whether Nix can/should “replace” Bazel: consensus leans toward simple build systems (cmake/meson/etc.) + Nix for dependencies and reproducible environments.
  • Buck2 mentioned as a promising, smaller‑core Bazel successor, but seen as immature: weaker ecosystem, tooling gaps, limited language support.

Nix/NixOS: power vs opacity

  • Enthusiasts describe Nix as extraordinarily versatile: cross‑compiling, static builds, containers/images, shared binary caches, reproducible environments across OSes.
  • Many say Nix fundamentally changes how they think about systems, dependencies, and determinism.
  • Counterpoint: Nix and its ecosystem are viewed as “opaque,” “inscrutable,” with a steep, time‑intensive learning curve, many conventions, and weak discoverability.
  • Suggestions for learning: start with Nix on an existing OS, use flakes + direnv, read the three core manuals, lean on official docs and community forums, and expect substantial investment.

Editors and programmable environments

  • Emacs repeatedly cited as archetypal enlightenmentware: deeply programmable, turns mundane tasks into engaging “system‑shaping.”
  • Modal variants (Evil, Doom, God mode) divide opinion; some embrace them, others stick to “native” Emacs keybindings.
  • Other “pervasively programmable” systems mentioned: Smalltalk/Pharo, Squeak, Lisp machines, Acme/Sam; praised for live, inspectable, reconfigurable environments.

Operating systems

  • Several note a lifecycle from Linux zealotry to more pragmatic use of macOS or Windows.
  • Mixed views on Windows: from “great OS” for many users to frustrating, noisy, and opaque; WSL is often cited as its saving grace for developers.
  • NixOS and Guix are viewed as “OS‑level enlightenmentware” for declarative, versioned system configs.

Other cited enlightenmentware

  • Docker and Podman for reproducible, isolated environments and reviving “ancient” projects.
  • Git (plus Magit, lazygit, VS Code UX) as a conceptual leap over centralized VCS.
  • LaTeX (and LyX/TeXmacs), Jupyter/web playgrounds, compiler explorer, Python Tutor for interactive learning and sharing.
  • Languages and runtimes: Haskell, TypeScript, Go’s tooling, JAX, Agda, Common Lisp, React/Redux, Cycle.js; praised for changing how people reason about programs.
  • LLMs (ChatGPT et al.) and LSPs described as recent, everyday “enlightenmentware” for many.

Design & philosophy notes

  • Contrast between “re‑editable” vs merely reusable code; many value systems that are easy to understand and modify.
  • Discussion of declarative/functional styles and effect systems as long‑term winners for maintainability.
  • Strong skepticism toward heavy dependency injection frameworks (e.g., Spring); DI as a concept is defended, but framework magic and complexity are criticized.