You can't do that because I hate you

Original Article ↗ Hacker News Discussion ↗

Programmers debate when developer tools should strictly enforce rules versus adapt to what users clearly intend. Examples range from Python’s REPL printing a scolding hint instead of just exiting, to Rust tooling that exposes “unstable” but useful features or removes once-working flags, forcing users into convoluted workarounds. Many see these patterns as a lack of empathy and UX thinking in tool design, while others argue that permissive behavior, DWIM shortcuts, and experimental options can create long‑term chaos and compatibility problems.

Python REPL exit Behavior

  • Debate centers on typing exit vs exit() in the Python REPL.
  • Some see the current behavior (printing a hint string via repr(exit)) as condescending: the interpreter detects intent but refuses to exit.
  • Others argue it’s a reasonable compromise:
    • Keeps semantics consistent (functions don’t run without ()).
    • Avoids special-casing that would break tooling relying on REPL consistency or repr() being side‑effect free.
  • Alternatives proposed:
    • Special-casing exit in the REPL only.
    • Printing both the function repr and a hint.
    • Warnings or REPL-specific hints, rather than altering __repr__.
  • ipython’s friendlier handling (exit just works) is cited as proof a better UX is possible.

“Do What I Mean” vs Strictness

  • One side: tools should act on clearly unambiguous intent (e.g., exit, -? for help, -foo when --foo exists). Ignoring clear intent feels hostile and wastes time.
  • Other side: DWIM behavior becomes part of the spec, introduces ambiguity, and can cause worse failures when guesses are wrong (e.g., semicolon insertion, browsers’ permissive HTML).
  • Many argue hints and clear errors are preferable to automatic fixes.

Rust Tooling and Unstable Features

  • rustfmt’s wrap_comments and cargo vendor’s removed --no-merge-sources flag are flashpoints.
  • Critics: gating simple, obviously useful features behind nightly or removing flags with unhelpful messages feels like “the tool knows what I want but refuses.”
  • Defenders: formatting and vendor behavior have tricky edge cases; “unstable” avoids mass churn in diffs and CI, and implementation is nontrivial. Backlogs and prioritization are constraints, especially in volunteer projects.
  • Some find the nightly/stable split too coarse: small utility functions or formatter options shouldn’t require nightly.

CLI Ergonomics and Help Flags

  • Repeated annoyance at tools that:
    • Reject -? or -h while suggesting another help flag.
    • Enforce strict option ordering (git log --stat directory).
  • Many favor accepting multiple help invocations and more forgiving parsing, especially for help-related actions.

Defaults, “Don’t Suck” Buttons, and Empathy

  • “Don’t suck” buttons: off‑by‑default options that make software behave as most users expect, with no obvious downside.
  • Tension between:
    • Improving UX for new/typical users with better defaults and messages.
    • Not breaking workflows of existing or power users, and not overcomplicating implementations.
  • Several comments call for more empathy, clearer communication of “why” decisions were made, and better attention to interaction design for CLIs and APIs.