Una súplica por un software austero (1995)

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

Los programadores revisitan la “Plea for Lean Software” de Niklaus Wirth de 1995 a la luz de las apps actuales, lentas y ávidas de memoria, argumentando que las herramientas y marcos modernos a menudo desperdician enormes avances de hardware por una conveniencia marginal. Muchos culpan a los incentivos organizacionales que premian lanzar funciones por encima del rendimiento, al auge de stacks pesados como Electron y a la dependencia de componentes amplios y genéricos en lugar de piezas enfocadas y bien comprendidas. Otros responden que una funcionalidad más rica, Unicode, edición remota e infraestructura de sistema compleja añaden inevitablemente peso, y que para muchos usuarios y empresas el intercambio sigue siendo aceptable mientras la velocidad percibida sea “suficientemente buena”.

SO, servicios en segundo plano y control del usuario

  • Muchos se quejan de que las aplicaciones comerciales inician automáticamente servicios en segundo plano (VPN, Steam, apps de chat) principalmente para actualizaciones/telemetría en lugar de aportar valor al usuario.
  • Se critica a Windows por dificultar deshabilitar esos servicios y por deshacer configuraciones del usuario (p. ej., políticas de AV), mientras que macOS se considera más controlable por el usuario.
  • Algunos sugieren servicios de actualización a nivel del SO con los que las apps puedan registrarse, pero dudan de que los desarrolladores los adopten frente a actualizadores personalizados.

Editores, funciones y bloat percibido

  • Editores antiguos que usan unos pocos MB se reinterpretan como “austeros” en comparación con herramientas modernas como VS Code/JetBrains.
  • Un lado sostiene que las funciones modernas (Unicode, emoji, desarrollo remoto enriquecido, análisis LSP, vistas previas) justifican inherentemente un mayor uso de recursos.
  • Otros replican que esas funciones pueden implementarse con mucho menos código; a menudo se eligen marcos grandes y motores de navegador por defecto, no por necesidad.
  • Se enfatiza que la capacidad de respuesta y la latencia de entrada son más importantes que el uso bruto de RAM.

Dependencias, bibliotecas y stacks Electron/web

  • Se debate entre bibliotecas compartidas y empaquetado: DLL-hell y los problemas de distribución empujaron a muchos a incluirlo todo en un paquete grande.
  • Algunos abogan por bibliotecas pequeñas, creadas para un fin concreto; otros prefieren bibliotecas convencionales (p. ej., grandes renderizadores de tipografías) por su fiabilidad y mantenimiento compartido.
  • Electron es un imán de críticas: se ve como un habilitador de iteración rápida y desarrollo multiplataforma, pero también como un emblema del despilfarro (múltiples navegadores integrados, alto uso de RAM/CPU).
  • Se sugieren las PWA como punto intermedio, aunque carecen de APIs nativas sin maquinaria adicional.

Incentivos organizacionales y proceso

  • Se dice que las grandes organizaciones recompensan las funciones y el optimismo, no el rendimiento; las pequeñas ralentizaciones incrementales se acumulan hasta que los sistemas se vuelven intolerables.
  • Se critican los procesos ágiles/empresariales, el CI/CD pesado y los equipos grandes por inflar el esfuerzo y las líneas de código sin mucha salida real.
  • El rendimiento como función central existe en nichos (trading, búsqueda/anuncios) donde el tiempo se monetiza directamente; en otros casos suele quedar relegado.

Hardware, usuarios y pruebas

  • Algunos sostienen que “el hardware es barato, el tiempo es caro”, justificando herramientas más pesadas.
  • Otros señalan que muchos usuarios tienen máquinas modestas; ejecutar varias aplicaciones pesadas (Slack/Teams, IDEs, navegadores, herramientas Electron) vuelve lentos los sistemas.
  • Probar en hardware antiguo o de gama baja se propone como una disciplina para mantener el software austero.

Responsabilidad y ethos del software austero

  • Varios insisten en que los desarrolladores deben hacerse cargo del rendimiento, elegir arquitecturas rápidas por diseño y evitar la abstracción gratuita y los marcos genéricos.
  • Otros destacan las fuerzas del ecosistema y económicas (dependencias compartidas, incentivos laborales, cultura de gestión) que estructuralmente favorecen el bloat.
  • Hay un optimismo cauteloso respecto a un contramovimiento de herramientas centradas en el rendimiento, pero escepticismo sobre que vaya a revertir ampliamente las tendencias de bloat.