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

Original Article ↗ Hacker News Discussion ↗

Efforts to “democratize” robotics by hiding complexity behind ultra-simple APIs are criticized as unrealistic given how messy and unpredictable the physical world is. Commenters argue that once you start programming robots you are, in effect, a roboticist, so tools should target competent peers and remove accidental complexity rather than chase mythical non-experts—using ROS, industrial robots, and bad UX patterns (like Microsoft Teams) as concrete examples. The thread also touches on how IEEE Spectrum’s editorial direction, open‑source licensing shifts, and education tools like LEGO Mindstorms fit into the broader tension between accessibility, robustness, and real‑world reliability in robotics.

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.