UI is hell: four-function calculators

Original Article ↗ Hacker News Discussion ↗

Simple four‑function calculators turn out to be surprisingly complex once you account for hidden state, edge cases, and decades of accumulated UX conventions such as percent keys, repeated equals behavior, and operator precedence (or lack of it). Commenters compare classic accumulator-style calculators, modern expression-evaluating apps, and Reverse Polish Notation (RPN), debating which is easier to reason about for both users and implementers. Many see these quirks as examples of how entrenched design choices and opaque state make even basic interfaces hard to predict, while others argue for stricter consistency or alternative input models.

Calculator behavior & hidden state

  • Many comments expand on how four-function calculators are effectively small state machines with an accumulator, last-operator registers, and special rules for = presses, sign change, etc.
  • Some argue the article overstates complexity: many “edge cases” can simply be treated as no-ops, which is what cheap devices do.
  • Others say those edge cases are emergent from a simple ASIC state machine rather than hand-coded special handling.
  • One detailed explanation frames basic calculators as accumulator-based “prefix” machines that only look infix: each operator finalizes the previous operation and prepares for the next operand.

RPN vs infix and operator precedence

  • Strong thread around Reverse Polish Notation (RPN): several people find it conceptually cleaner, easier to implement, and more predictable than infix-with-hidden-state.
  • Counterpoint: RPN pushes more cognitive load to the user (managing stack depth, figuring input order for nested expressions), and can be awkward for algebraic manipulation.
  • Debate on PEMDAS: some call operator precedence a historical mistake or irrelevant to four-function calculators; others insist precedence is essential for “correct” calculators that evaluate full expressions.
  • Several note that many pocket calculators ignore precedence and evaluate strictly left-to-right; scientific models typically implement precedence, often via internal stacks.

Percent, equals, and other quirks

  • Percent key behavior is widely viewed as confusing; implementing “100 – 5% = 95” correctly on tiny hardware is praised as a clever language hack.
  • Repeated = presses (K-constant behavior) differ across devices and apps; some calculators repeat the last operation, others (e.g. a recent iOS version) did nothing, which drew criticism.
  • Confusion persists around clear modes (C vs CE) and calculator-specific behaviors (e.g., unusual “x÷” combo keys on vintage models).

Hardware, power, and longevity

  • Several reminisce about real solar calculators versus fake “decorative” panels, noting how little power classic LCD calculators used.
  • Dedicated calculators are praised for outlasting “smart” devices that depend on servers or complex software stacks.

Modern OS calculators & UX lessons

  • System calculators (iOS, Android, Windows, macOS) are criticized for inconsistent behavior, precedence handling, and subtle UI changes that break expectations.
  • Some users now rely on RPN apps, full-expression scientific calculators, or even slide rules and custom tools.
  • Recurrent theme: hidden state and trying to handle every weird input path make UIs fragile; better to define a small, consistent model and let invalid sequences be no-ops.