The Mythical Non-Roboticist: Wouldn't it be great if everyone could do robotics?

Original Article ↗ Hacker News Discussion ↗

UI/UX and “Decluttering” Problems

  • Multiple comments branch into a critique of modern UX: hidden options, over-decluttering, and “flydropping” menus that require web searches to perform simple actions.
  • Microsoft Teams is cited repeatedly as an especially bad example: confusing muting/notification behavior, unreliable cross-device interactions, vanishing meetings, delayed or missing messages.
  • Broader frustration with phone alarms/notifications: alarms failing after updates, subtle volume/mode interactions, unclear silent-mode behavior, and “smart” features that silently change behavior.
  • Some defend thoughtful decluttering (e.g., consolidating play/pause), but others warn that burying core actions (e.g., under hamburger menus) makes things worse.

Quality and Role of IEEE Spectrum

  • Some see the article as “Discovery Channel”-style popularization and a decline in IEEE Spectrum’s rigor.
  • Others argue it is a legitimate practitioner-to-practitioner piece about API design for robotics, not pop science.
  • A gatekeeping tension appears: whether IEEE should stay “for professionals” or welcome broader, more accessible discussions.

Who Robotics APIs Should Be For

  • One side echoes the article’s stance: designing for a vague “non-roboticist” produces brittle, oversimplified tools. Once someone programs a robot, they effectively are a roboticist; tools should target capable peers and remove unnecessary, not essential, complexity.
  • Opposing view: the real goal is robots that ordinary people can use like dishwashers or elevators. If APIs like grab_object are hard to make reliable, that reflects the current limits of perception/manipulation, not a bad goal.

ROS and Robotics Tooling

  • Several see the piece as an implicit critique of ROS: configuration as “markup-as-programming,” opaque failures, and steep learning curves that discourage newcomers.
  • ROS 1 is described as imperfect but battle-tested; ROS 2 as more powerful but significantly more fragile and hard to debug (DDS issues, Python slowness, tooling churn).
  • Defenders emphasize ROS’s real value as a standardization layer (common message types, frames, interoperability) more than its middleware.
  • There is skepticism that any monolithic framework can “make robotics simple”; alternatives (various middlewares, commercial platforms) are mentioned but not seen as clear successors.

Democratization of Skills and Education

  • Several draw parallels to other domains (comics, music, programming): “democratizing” via tools can trade away depth and encourage shallow, popularity-driven creation.
  • Others defend simplified platforms (Lego Mindstorms, line-following kits) as on-ramps that build passion; serious work still requires moving to more complex, powerful tools.
  • Consensus that entry-level robotics has never been easier, but turning that into robust, real-world systems remains very hard.

Inherent Difficulty of Robotics

  • Multiple comments echo the article’s “world as global mutable state” framing: real environments are noisy, dynamic, and only partially observable.
  • Even drastically simplified problems (2D arms with perfect state) can be surprisingly hard to automate compared to human teleoperation.
  • Some highlight that robotics difficulty also stems from configuration, drivers, and integration, not just algorithms.

Definitions and Scope of “Robot”

  • Academic definitions make many everyday systems “robots” (dishwashers, missiles, elevators), but colloquially people reserve the term for more visibly mobile or anthropomorphic systems.
  • One pithy view: “a robot is a machine that doesn’t work yet”; once reliable, it stops being called a robot.
  • Others embrace the broad definition and celebrate mundane, reliable “robots” as successes.

Industrial vs General-Purpose Robots

  • Strong agreement that constraining environment and tasks (assembly lines, warehouse AGVs, teach-pendant arms) makes robotics tractable.
  • “General-purpose” robots that handle unconstrained tasks in open environments are seen as qualitatively harder.
  • Learning advice: start with highly constrained, concrete projects and specific goals rather than ambitious “do-anything” humanoids.