No puedes hacer eso porque te odio

Artículo original ↗ Discusión en Hacker News ↗

Los programadores debaten cuándo las herramientas para desarrolladores deben aplicar reglas de forma estricta y cuándo adaptarse a lo que los usuarios claramente quieren decir. Los ejemplos van desde la REPL de Python, que muestra una pista regañona en vez de simplemente salir, hasta herramientas de Rust que exponen funciones “inestables” pero útiles o eliminan banderas que antes funcionaban, obligando a los usuarios a recurrir a soluciones enrevesadas. Muchos ven estos patrones como falta de empatía y de pensamiento de UX en el diseño de herramientas, mientras que otros sostienen que el comportamiento permisivo, los atajos DWIM y las opciones experimentales pueden generar caos y problemas de compatibilidad a largo plazo.

Comportamiento de exit en la REPL de Python

  • El debate se centra en escribir exit frente a exit() en la REPL de Python.
  • Algunos ven el comportamiento actual (imprimir una cadena de pista mediante repr(exit)) como condescendiente: el intérprete detecta la intención pero se niega a salir.
  • Otros sostienen que es un compromiso razonable:
    • Mantiene la semántica consistente (las funciones no se ejecutan sin ()).
    • Evita casos especiales que romperían herramientas que dependen de la consistencia de la REPL o de que repr() no tenga efectos secundarios.
  • Alternativas propuestas:
    • Tratar exit como caso especial solo en la REPL.
    • Imprimir tanto la representación (repr) de la función como una pista.
    • Advertencias o sugerencias específicas de la REPL, en lugar de alterar __repr__.
  • Se cita el manejo más amable de ipython (exit simplemente funciona) como prueba de que una mejor UX es posible.

“Haz lo que quiero decir” frente a la estricta corrección

  • Un lado: las herramientas deberían actuar sobre una intención claramente inequívoca (por ejemplo, exit, -? para ayuda, -foo cuando existe --foo). Ignorar una intención clara se siente hostil y hace perder tiempo.
  • El otro lado: el comportamiento DWIM pasa a formar parte de la especificación, introduce ambigüedad y puede causar fallos peores cuando las suposiciones son erróneas (por ejemplo, la inserción de punto y coma, el HTML permisivo de los navegadores).
  • Muchos argumentan que las pistas y los errores claros son preferibles a las correcciones automáticas.

Herramientas de Rust y características inestables

  • wrap_comments de rustfmt y la bandera eliminada --no-merge-sources de cargo vendor son puntos de conflicto.
  • Críticos: limitar funciones simples y obviamente útiles detrás de nightly o eliminar banderas con mensajes poco útiles se siente como “la herramienta sabe lo que quiero, pero se niega”.
  • Defensores: el formateo y el comportamiento de vendor tienen casos límite complicados; lo “inestable” evita cambios masivos en diffs y CI, y la implementación no es trivial. Los atrasos y la priorización son limitaciones, especialmente en proyectos impulsados por voluntarios.
  • Algunos consideran que la división entre nightly y stable es demasiado gruesa: funciones pequeñas de utilidad o opciones del formateador no deberían requerir nightly.

Ergonomía de la CLI y banderas de ayuda

  • Molestia repetida con herramientas que:
    • Rechazan -? o -h mientras sugieren otra bandera de ayuda.
    • Imponen un orden estricto de las opciones (git log --stat directory).
  • Muchos prefieren aceptar múltiples invocaciones de ayuda y un análisis más flexible, especialmente para acciones relacionadas con la ayuda.

Valores predeterminados, botones de “no fastidies” y empatía

  • Botones de “no fastidies”: opciones desactivadas por defecto que hacen que el software se comporte como la mayoría de los usuarios espera, sin desventajas obvias.
  • Tensión entre:
    • Mejorar la UX para usuarios nuevos o típicos con mejores valores predeterminados y mensajes.
    • No romper los flujos de trabajo de usuarios existentes o avanzados, y no complicar en exceso las implementaciones.
  • Varios comentarios piden más empatía, una comunicación más clara del “por qué” de las decisiones y una mejor atención al diseño de interacción para CLI y API.