¿La abstracción del software destruye la civilización? (2021)

• La preocupación de Jonathan Blow de que “la abstracción debilita la capacidad de mantener software esencial” es válida en términos de transmisión del conocimiento, pero muchos de los ejemplos que usa interpretan mal la historia y el contexto
• Los debates sobre “five nines”, software robusto, estancamiento del progreso tecnológico y caída de la productividad dependen en gran parte de no distinguir entre dispositivos de consumo y sistemas de alta disponibilidad o de ejemplos seleccionados de forma sesgada
• La preocupación por la pérdida de conocimiento de bajo nivel es parcialmente válida, pero C, ensamblador, Rust, el porting de sistemas operativos, la enseñanza de compiladores y la actividad de código abierto siguen siendo vías para preservar las capacidades de sistemas
• Las abstracciones como sistemas operativos, sistemas de archivos, redes, multitarea y frameworks aumentan la complejidad, pero también permiten afrontar los cambios del hardware y las expectativas de los usuarios, además de mejorar la portabilidad, productividad y accesibilidad para crear
• Más que la abstracción en sí, los mayores riesgos son el churn constante, las plataformas cerradas, la publicidad, los rastreadores, la telemetría y el debilitamiento de la privacidad y la libertad; la base técnica para mantener sistemas críticos debe seguir preservándose

---

Postura básica frente al argumento de Blow

• La charla de Jonathan Blow plantea que la abstracción del software provoca la pérdida de conocimiento de programación de bajo nivel y que, al final, eso podría llevar al colapso de la civilización al no poder mantener software esencial
• Se puede estar de acuerdo con la importancia de transmitir el conocimiento, pero para sostener una afirmación así los ejemplos y el contexto histórico deben ser precisos
• La réplica principal es que los ejemplos de Blow dependen mucho de malentendidos, casos elegidos selectivamente y evidencia anecdótica, además de pasar por alto partes de la historia de la computación

El debate sobre “five nines” y la robustez

• Blow afirma que en el pasado, al vender sistemas informáticos, se usaba “five nines”, es decir, 99.999% de tiempo activo, como argumento de calidad, pero que las laptops actuales no llegan a eso
• Es cierto que five nines significa unos 5 minutos de caída al año, pero se considera incorrecta la afirmación de que esa métrica se usara para vender laptops de consumo o procesadores de texto
  • Five nines suele aplicarse a ámbitos como centrales de respuesta de emergencia tipo 911, sistemas hospitalarios o procesamiento de transacciones financieras
  • A menudo se usa junto con contratos de largo plazo que detallan qué situaciones no cuentan como tiempo caído
  • Empresas como IBM y Amazon siguen vendiendo este tipo de sistemas y servicios
• También hay contraejemplos a la idea de que no se produce software robusto desde hace décadas
  • Un iPhone puede funcionar durante semanas o meses sin reiniciarse
  • Hay un caso de 16 años de tiempo activo en un servidor de archivos e impresión de Novell
  • También se mencionan como ejemplos de disponibilidad prolongada equipos Unix, Windows, VMS y sistemas llave en mano como IBM i

Réplica sobre progreso tecnológico y productividad

• Se concede parcialmente la frase de que “las empresas tecnológicas ya no empujan la tecnología”, pero las compañías que priorizan más el dinero también existían antes
• Áreas “aburridas” como sistemas de archivos, servidores web, bases de datos y lenguajes de programación siguen desarrollándose y mejorando
• Las capas de abstracción, virtualización y contenedorización que Blow detesta también siguen mejorando gracias a mucho trabajo, y que no le gusten no significa que no sean progreso tecnológico
• La afirmación de que la productividad de los empleados de Facebook se acerca a cero depende de asumir que el producto de Facebook son solo funciones de plataforma social
  • Los empleados de la empresa Facebook incluyen roles como legal, contabilidad, diseño gráfico, administración de sistemas, investigación, RR. HH. y mandos medios
  • También existen otros negocios como Instagram, WhatsApp y Oculus VR
  • El verdadero producto de Facebook es una plataforma de entrega de anuncios, y convertir datos personales y privados en publicidad dirigida genera ingresos aunque no se vea como una función para el usuario

El conocimiento de bajo nivel y el doble filo de la abstracción

• Se reconoce como cierto que muchos programadores prefieren entornos donde no tengan que lidiar con asignación de memoria ni punteros
• Se considera problemático el exceso de abstracción, como renderizar un blog simple con frameworks innecesarios de JavaScript o apps de escritorio lentas que corren dentro de un navegador empaquetado
• Sin embargo, hoy podría haber más personas capaces de usar C y más código escrito en C y ensamblador que antes
  • Linux y NetBSD siguen porteándose a una amplia variedad de objetivos que se comportan como CPU
  • Rust ofrece punteros y manejo de memoria con foco en la robustez
  • Harvard CS50 cubre temas como layout de memoria, punteros, malloc() y free() en clases abiertas al público
• La recolección de basura y la programación funcional no son abstracciones nuevas
  • Lisp ya ofrecía ambas desde finales de los años 50
  • Lisp también se usó en entornos “hardcore” como el Jet Propulsion Lab de la NASA
• COBOL no aparece en la charla de Blow, pero sigue siendo un lenguaje de alto nivel fundamental para la banca y la infraestructura financiera, y por tanto importante para el nivel actual de la civilización

El caso del “Unix en 3 semanas” de Ken Thompson

• Se considera un logro extraordinario que Ken Thompson construyera en 3 semanas un ensamblador, un editor y un kernel básico
• Aun así, no está claro qué tan robusto era ese software en ese momento, qué tan amigable era para el usuario ni qué funciones tenía
• Las condiciones de trabajo de entonces y las de hoy son muy distintas
  • El desarrollo actual incluye documentación, revisión de código, daily standups, limpieza de backlog, historias de usuario, pruebas unitarias, requisitos de clientes, pruebas A/B, mensajes de commit y estándares corporativos de código
  • También puede haber diferencias entre un entorno interrumpido de oficina abierta y un entorno de trabajo individual al estilo Bell Labs
• Un solo caso como el de Thompson no demuestra que todos los programadores del pasado fueran más productivos
  • Thompson también participó en Multics, famoso por sus retrasos
  • Grandes proyectos como IBM OS/360 también sufrieron retrasos prolongados, y Frederick P. Brooks escribió en 1975 The Mythical Man-month a partir de esa experiencia

Evolución del software y expectativas de los usuarios

• En general, las computadoras se han vuelto más robustas que hace décadas, y se considera que los programadores son al menos tan productivos como antes
• Aun así, en algunos casos empezar puede ser más complicado y eso reduce la productividad inicial
• Los usuarios modernos no quieren aprender RPN para hacer aritmética simple ni escribir directivas de troff para diseñar un volante
• Las interfaces convenientes y las funciones avanzadas aumentan la complejidad y el tiempo de desarrollo independientemente de la abstracción
• El caso de un viejo Amiga OS que se caía al copiar archivos y corrompía particiones del disco duro muestra que los sistemas del pasado no eran necesariamente más estables
  • Los sistemas operativos modernos de computadoras domésticas tienen protección de memoria y sistemas de archivos con journaling, por lo que ese tipo de problema ocurre mucho menos
  • Windows 10 Home también tiene defectos, pero incluye esos avances

Las afirmaciones de “antes simplemente se podía hacer”

• Copiar y ejecutar programas

  • Copiar un programa de una computadora a otra y ejecutarlo sigue siendo posible si se mantiene la misma arquitectura objetivo y las mismas condiciones de compilación
  • Se menciona el caso de un binario con enlace estático de slack-term compilado en Go que funcionó en varias Raspberry Pi
  • Aun así, para encontrar una época en la que los programas independientes fueran realmente comunes habría que retroceder a los tiempos de la C64 o la PC/XT, y hasta Deluxe Paint IV en Amiga dependía de varios archivos auxiliares y bibliotecas de funciones de terceros
  • Algunos juegos de Amiga usaban disquetes cargados por pista que evitaban el sistema de archivos y funcionaban como una especie de contenedor de la época, aunque con la desventaja de impedir la instalación en disco duro y la multitarea

• La afirmación de que si el CPU es el mismo, el código corre

  • En teoría, es posible cargar código máquina en memoria y apuntar el contador de programa para ejecutarlo en un CPU igual
  • Pero para tareas reales como salida gráfica, reproducción de sonido, manejo de entrada y escritura en disco, las diferencias de hardware son un problema importante
  • Incluso las computadoras domésticas antiguas basadas en Z80 compartían CPU, pero diferían en su hardware periférico, así que el porting real era difícil
  • De hecho, programas con un nivel de abstracción más alto como Basic podían portarse con más facilidad entre distintas máquinas
  • Ahora que Apple lanzó una línea de escritorio basada en ARM, depender de abstracciones puede reducir el costo de portar a un nuevo CPU en comparación con programar pegado directamente al metal

• Sistemas operativos y acceso al hardware

  • Los sistemas operativos no solo quitan capacidades del CPU, también agregan funciones como sistema de archivos, red y multitarea
  • Usuarios como los streamers de Twitch, que necesitan ejecutar juegos junto con otros programas, requieren multitarea para repartir recursos de hardware de forma administrada y predecible
  • Parte del software de Amiga y Atari accedía directamente al hardware y a la memoria sin seguir las especificaciones y abstracciones provistas por el fabricante, por lo que dejaba de funcionar incluso con pequeñas mejoras como más memoria o un disco duro
  • El software escrito conforme a las especificaciones y abstracciones podía seguir vendiéndose después de cambios en el hardware

• Gráficos, programas sin firma y LSP

  • Dibujar píxeles en pantalla sigue siendo posible en varios lenguajes, y Mode 13h también se accedía mediante una capa temprana de abstracción de hardware: el BIOS VGA
  • El código que dependía de hardware VGA específico no era portable, pero los programas gráficos que usaban abstracciones de Windows podían funcionar desde Hercules hasta true-color XGA en entornos muy distintos
  • También es posible ejecutar programas sin firma, y se menciona el caso de compilar WordGrinder manualmente para usarlo
  • Parte de las quejas de Blow se parece más a un problema de fabricantes de hardware y software que cierran los sistemas y reducen el control del usuario que a un problema de abstracción
  • En cuanto al Language Server Protocol, en general se coincide bastante con Blow, pero LSP resuelve más problemas que simplemente “hacer clic en un método para ir a su definición”

Juegos, rendimiento y multitarea

• Entre las apps modernas de productividad hay muchos casos con degradación de rendimiento y retraso serio en la entrada
• Parte de la causa es la abstracción, pero un problema mayor es el mal código y la elección de herramientas inadecuadas para la tarea
• Incluso programas que usan la misma plataforma y el mismo toolkit de UI pueden tener rendimientos percibidos muy distintos en la misma máquina
• El problema que Blow muestra en un juego que no restaura bien la resolución después de Alt-Tab es una mala experiencia y debería corregirse
• Pero los juegos de DOS del pasado eran más simples porque no necesitaban preocuparse por otros procesos
  • Para jugar Doom en Windows 3.1 había que guardar el trabajo, cerrar los programas, salir de Windows y luego iniciar el juego
  • Muchos juegos de Amiga también arrancaban desde disquete, tomaban por completo la máquina y no regresaban limpiamente al sistema operativo
• La multitarea en juegos hoy no es perfecta, pero se considera mejor que antes

Pérdida de conocimiento y velocidad del cambio

• Blow ve conocimientos como la gestión de sprites en Unity como una especie de trivia que reemplaza una comprensión profunda
• Se coincide en que muchas veces la velocidad de cambio del software y del hardware es tan alta que resulta difícil seguirle el ritmo de forma significativa
• Pero eso se parece más a un problema de consistencia a lo largo del tiempo y del modelo de distribución del software que de la abstracción en sí
• La dinámica de publicar algo cada 4 semanas puede dificultar que los usuarios tengan una experiencia estable
• Cuando la UI cambia con frecuencia, los usuarios terminan peleando con los detalles de una interfaz que no deja de cambiar en vez de concentrarse en su trabajo real

La complejidad es un problema creado por las personas

• Blow sostiene que, si se decide reducir la complejidad, se puede hacer, y que añadir abstracción para ahorrar tiempo es una ilusión
• Si se usa el framework correcto para el propósito correcto, puede ayudar mucho a un desarrollador web
• Al mismo tiempo, se mira con escepticismo la idea de hacer todo en el navegador, desde procesadores de texto hasta juegos, o de cambiar inmediatamente a cada framework nuevo que aparece
• La complejidad del software no es solo un problema de los programadores; también la crean el mercado y el entorno organizacional
  • La política interna, las reuniones sin sentido, el software incomprensible para reportar horas, los plazos impuestos desde fuera, los requisitos difíciles de los clientes, decisiones extrañas de gestión, estimar calendarios para requisitos abstractos y depurar código legado afectan las decisiones de los desarrolladores
• La complejidad es un problema creado por personas, y reducir la complejidad en el trabajo podría disminuir también la complejidad del software a largo plazo

Jóvenes desarrolladores y capacidad de crear motores

• La afirmación de Blow de que los jóvenes desarrolladores de juegos nunca han escrito su propio motor y que pronto esa capacidad podría olvidarse colectivamente se parece a una pendiente resbaladiza
• La mayoría de quienes tenían una C64, una Amiga o una PC 286 no se volvieron desarrolladores de bajo nivel, y muchos ni siquiera se volvieron programadores
• Las abstracciones y los motores de juego ya hechos permiten crear sin dominar gestión de memoria de bajo nivel, punteros o algoritmos
• Hoy los niños quieren hacer algo parecido a los juegos AAA que compran en la tienda, y las expectativas sobre los juegos modernos son mucho más altas que en la época de la C64 o la Amiga
• Los caminos para aprender técnicas de bajo nivel siguen existiendo
  • Linux atrae a desarrolladores jóvenes a través de la comunidad de código abierto y despierta interés por lenguajes de sistemas como Rust, C y C++
  • dwm es un gestor de ventanas que se configura modificando su código fuente en C
  • Existen jóvenes desarrolladores que usan C y ensamblador Z80, personas que construyen una distribución Linux desde cero, gente que crea su propio hardware y desarrolladores en C que ejecutan sistemas operativos de investigación en hardware moderno
  • Las carreras de ciencias de la computación e ingeniería eléctrica siguen enseñando fundamentos como C, ensamblador y diseño de compiladores
  • El acceso a herramientas de programación, bibliografía, videos educativos y materiales como MIT OpenCourseWare es más barato y mejor que antes

Juicio final: problemas más grandes que la abstracción

• La conclusión de Blow se parece a una forma de survivalismo aplicada a la tecnología, y resulta comprensible la analogía de que, cuando se va la luz, hace falta alguien que sepa prender fuego
• La sociedad depende de la capacidad de mantener algunos programas funcionando casi de manera continua
  • Si eso falla, puede haber consecuencias graves como el colapso de la economía mundial o el fracaso de un sistema nacional de salud
  • Como los registros históricos y modernos se almacenan cada vez más en formato digital, deben seguir siendo accesibles en el futuro
• La complejidad es frágil y la abstracción puede producir ignorancia dañina; un blog simple no necesita shadow DOM y un cliente de IRC con imágenes no necesita una carcasa de navegador
• Pero el churn artificial y constante también es una gran fuente de fragilidad
  • El desarrollo “Agile” busca no lanzar cosas sin terminar y sin probar, pero en la práctica siguen saliendo versiones incompletas
  • Los sistemas de anuncios, rastreadores y telemetría actúan en la práctica como puertas traseras por diseño y agregan vulnerabilidad e inseguridad
• El problema más grande del mundo digital es la privacidad y la libertad
• La razón por la que podría dejar de ser posible interactuar directamente con el hardware no sería haber elegido abstracción, sino terminar en un mundo donde solo queden plataformas cada vez más cerradas y controladas a distancia

[GN⁺]

Opiniones de Hacker News

• En Montana State doy una clase de sistemas que va desde transistores hasta sistemas de cómputo reales, y hay estudiantes que empiezan el curso sin saber bien qué es un sistema de archivos.
  Blow se equivoca en algunos detalles, pero creo que, para los estudiantes de áreas técnicas, deberíamos considerar seriamente una educación tipo NAND-to-Tetris desde la secundaria.
  Uso modelos “viejos” como Little Man Computer o un emulador visual sencillo de MIPS; aunque no sean realistas, dan una idea de dónde venimos con una complejidad que una persona normal puede entender.
  Cuando veo los libros de arquitectura de 64 bits que se recomiendan hoy, solo me da risa; conectar la tecnología hasta sus raíces es un problema difícil.

  • Los conceptos de archivo y sistema de archivos también son útiles para usuarios comunes de computadora que no tienen interés en el funcionamiento interno.
    El problema es que los sistemas operativos móviles y las empresas de software intentan convertir los datos del usuario, tanto como sea posible, en jardines amurallados dentro de las apps.
    Aunque ya estés trabajando con archivos, te obligan a “importar” los datos existentes a su propio almacenamiento, y las versiones modificadas hay que “exportarlas” o “compartirlas” manualmente como copias nuevas.
  • Yo también soy bastante cercano a un viejo gruñón, pero ya dejé de tener expectativas sobre la generación actual de “universitarios”.
    Estoy haciendo una maestría en ingeniería industrial en Montana State, y todos los días trato con estudiantes de doctorado que no pueden hacer derivadas parciales simples.
    El semestre pasado, en una materia de matemáticas de nivel 400, también había estudiantes que no sabían sumar dos matrices.
    Que un estudiante de cuarto año de ciencias de la computación no conozca los sistemas de archivos también es raro, pero comparado con las cosas absurdas que he visto aquí, hasta parece modesto.
    Me deprime mucho lo distinto que se siente esto frente a cuando fui por primera vez a la universidad en los años 2000, pero la perspectiva del mercado laboral para la próxima primavera más bien me da confianza.
  • Depende de la carrera. Ciencias de la computación, ingeniería en computación e ingeniería electrónica son áreas distintas.
    Pese al nombre, ciencias de la computación no es el estudio de las computadoras en sí; aunque la computadora sea una herramienta indispensable, el núcleo está en la abstracción de dominios, el modelado de lenguajes y su aplicación.
    Así como un astrónomo solo necesita saber manejar un telescopio lo suficiente, un científico de la computación solo necesita saber manejar una computadora lo suficiente.
    Poner a la computadora en el centro del universo y tomarla como punto de partida de las ciencias de la computación es un gran error, y también ha sido históricamente una fuente de mucha confusión.
    Incluso la programación de “bajo nivel” al final es abstracción y lenguaje; simplemente usa el lenguaje de un dispositivo de cómputo para simular abstracciones del dominio sobre el que se está hablando.
  • Aprendí arquitectura de computadoras con MIPS cuando MIPS todavía se usaba en productos reales, y me pareció bueno entonces y me sigue pareciendo bueno ahora.
    En mi tiempo libre descompilo ensamblador MIPS, y las funciones pequeñas puedo volverlas a convertir a código C correspondiente a mano, sin otras herramientas.
  • Enseñar está directamente relacionado con la afirmación de que “la información transmitida entre generaciones se diluye”.
    Pero no se diluye. Justamente porque existen la enseñanza, los libros y las computadoras no hace falta llamar bardos a los profesores.
    Al final, esto es otro post de blog sobre un post de blog, y no sé qué tan “importantes” sean esos blogueros, pero huele a blog por el blog.

• Cuando un desarrollador web veterano critica la abstracción, apunta a los desarrolladores de React; cuando la critica un desarrollador de Python, apunta a los desarrolladores web veteranos; y cuando la critica un desarrollador de aplicaciones en C++, apunta a los desarrolladores de Python.
  Los desarrolladores de firmware apuntan a los desarrolladores de aplicaciones, y los ingenieros eléctricos a los desarrolladores de firmware.
  Es una actitud bastante notable trazar la línea de la abstracción excesiva justo en el nivel que uno conoce y llamar a todo lo que viene después “matar la civilización”.

  • Exacto. Es casi lo mismo que esas tonterías ocasionales de “la química es física aplicada, y la física es matemática aplicada, así que la matemática es suprema”.

• Hay muchas buenas observaciones, y como también vi esa charla, creo que la crítica es importante.
  Aun así, Blow tiene razón cuando dice que “no se puede simplemente dibujar píxeles en la pantalla”.
  Trabajo como programador de motores de juego en una empresa mediana de videojuegos, y cada vez se vuelve más difícil contratar gente que pueda trabajar con código de gráficos.
  Las API de la generación de DX12 elevaron enormemente el nivel que se exige al programador frente a la generación anterior, DX11, y hacer algo con esta API ya es en sí mismo un trabajo grande.
  Microsoft alguna vez reconoció que aprender DX12 sin experiencia previa en API gráficas era extremadamente difícil, aunque ahora no encuentro esa cita en la documentación.
  La réplica de que “estas API son para desarrolladores que quieren llevar las tarjetas gráficas al límite y hacer optimizaciones de muy bajo nivel” tiene parte de razón, pero ahora se han convertido en el estándar de la industria y son casi imposibles de enseñar a alguien sin experiencia previa.
  Si algo no cambia, el grupo de personas contratables seguirá reduciéndose.

  • Al ver la charla de Blow sentí que no era raro que me frustrara porque las tareas básicas se han vuelto absurdamente difíciles.
    Al crear aplicaciones de software, incluso dibujar un solo botón en la pantalla se volvió tan difícil que la mayoría simplemente usa aplicaciones web progresivas, que son 100 veces más lentas de lo que podría lograrse.
    Me pregunto si en 2025 lo mejor para una aplicación GUI realmente son Java Swing y Qt.
  • Estoy de acuerdo con el punto principal, pero DX12 fue en la dirección opuesta a la abstracción. Es una API de mucho más bajo nivel que OpenGL, que estaba altamente abstraída.
  • O tal vez podrían volver los “desarrolladores aprendices”.
  • Lo que más necesita mejorar es la educación y documentación de estas nuevas API.
    Hay grandes conceptos que lo conectan todo, pero en la documentación casi ni se insinúan; solo se aprenden asistiendo a sesiones de capacitación o hablando con alguien que ya los conoce.

• Creo que cosas como JavaScript del lado del servidor y React realmente arruinaron el desarrollo de software web en relación con lo que realmente hacen.
  Hoy hay chicos que ni siquiera saben que lo que se renderiza en el navegador es HTML. Piensan que el navegador renderiza React en sí.
  Encima, el CEO de Vercel dijo una estupidez absoluta: que considera a React el kernel de Linux del desarrollo.

  • Es una afirmación rara, pero efectivamente lo dijo.
    https://news.ycombinator.com/item?id=42824720
    Llevo el tiempo suficiente como para recordar la época de vanilla js, jQuery, Knockout y Angular 1, pero incluso entonces siempre hubo confusión básica.
    React, y a veces incluso solo JSX, puede usarse de forma razonable.
    Más bien culpo a herramientas financiadas por venture capital como Vercel, Next, Apollo y Prisma, y a los influencers de desarrollo web que llenan la web de basura pagada.
    Si uno lo piensa, todo en la creación de software se infló, desde los tableros de Notion hasta elecciones dudosas de bases de datos.
  • Estoy de acuerdo en que es terrible que haya muchos desarrolladores jóvenes que no pueden programar sin React.
    Pero, como alguien que puede trabajar bien sin librerías, quiero agregar que el DOM es una de las peores API inventadas por la humanidad, y que la “programación reactiva” es un modelo superior al enfoque antiguo.
    NextJS revirtió años de mejoras en herramientas y es muchísimo más lento que Vite.
    En NextJS compilado de forma estática, una página sin ninguna interacción descarga 100 KB de JavaScript para no hacer nada.
    Facebook intenta resolver con un “compilador” para React algo que podría arreglarse simplemente haciendo que, por defecto, no vuelva a renderizar componentes inútilmente.
    Comparado con Preact, que puede reemplazarlo casi tal cual, React es enorme, y eso muestra lo poco que le importa a Facebook.
  • La frase “lo que renderiza el navegador es HTML” irónicamente es incorrecta, y quienes piensan que el navegador renderiza React están más cerca de tener razón.
    HTML es un formato de serialización, y el navegador lo usa para construir el DOM en memoria.
    React no serializa nada a HTML, sino que renderiza directamente en el DOM.
    Que esto haya recibido tantos votos positivos pese a estar mal deja claro el carácter de este hilo: “viejo gritándole a las nubes”.
  • En el contexto de modificar el DOM con JavaScript, no sé qué significa decir “el navegador renderiza HTML”.
    Según lo entiendo, HTML es la entrada del navegador, el navegador lo transforma en DOM y luego siguen el dibujo en pantalla, el manejo de entradas, etc.
    Esta diferencia es importante, porque React y las librerías JavaScript de tipo DOM virtual no generan HTML, sino instrucciones de manipulación del DOM en JavaScript.
  • Me parece que el punto central de React era justamente que no funciona en absoluto si no activas JavaScript, y que Facebook lo convierte en un desastre lo bastante grande como para ocultar eficazmente ahí dentro sus propias prácticas maliciosas.
    Hay muchas partes buenas en las críticas de Blow, pero creo que pasa por alto que gran parte del retroceso no proviene de una deriva generacional ni de la entropía de la información, sino de la mala fe explícita de quienes toman las decisiones.

• Blow muchas veces señala cosas excelentes sobre desarrollo, y otras veces se equivoca por completo.
  Ha logrado mucho y tiene ideas que vale la pena escuchar, pero también hay mucha basura presentada de forma indistinguible junto con eso.
  Sentí con fuerza que lo de la caída de la civilización era una de esas tonterías, y aunque lo escuché dos veces, en gran parte lo ignoré.
  Agradezco que el texto original haga una refutación más basada en principios.
  Creo que Casey Muratori imita a Blow, pero ni siquiera logra hacer bien las partes buenas.

  • Blow lleva casi 10 años haciendo un juego, y ni siquiera es un juego para el que necesitara reinventar la máquina.
    Muratori tampoco logró terminar el juego que empezó hace 10 años.
    En cambio, con motores de juegos modernos, incluso cosas como Raylib, se pueden lograr resultados bastante decentes en una game jam de fin de semana; y algo como el juego de Sokoban de Blow probablemente podría hacerse en unos seis meses, sobre todo con un equipo de unas 10 personas.
  • Me da curiosidad saber con qué partes de Casey Muratori no estás de acuerdo en concreto.
    Vi parte de su contenido y, sobre los temas que conoce, me pareció humilde pero con opiniones claras; además, creo que hizo un gran trabajo con Handmade Hero.
  • La afirmación central de Muratori parece ser que el software moderno es lento, y en eso creo que tiene 100% razón.
    Es una locura el tiempo que tarda Jira en mostrar un ticket, Slack en cambiar de sala de chat o VSCode en seguir el ritmo de una velocidad de tipeo normal.
  • No sé si realmente sea así.
    Parece que lanza críticas amplias y luego vuelve a desaparecer para no hacer nada.
    Tampoco se puede decir que haya logrado cosas extraordinarias; diría que hizo trabajos decentes.
    Solo lanzó dos juegos, y son más bien puzzles que juegos. Una vez que los terminas, casi no hay razón para volver a jugarlos.
    Braid está bien, y The Witness es simplemente como Flow.
    Después de eso lleva 10 años haciendo un lenguaje de programación, pero no lo publica porque “todavía no está terminado”.
    Desde que tuvo la suerte de ganar dinero, parece verse a sí mismo como alguien mucho más talentoso de lo que realmente es.

• Sin duda hay muchos problemas en el entorno de software moderno, y creo que la abstracción excesiva también es un problema.
  Pero el extremo opuesto también es malo, y también existe una tendencia a romantizar demasiado el pasado.
  Los cuelgues y reinicios también eran un problema; sistemas como Amiga tenían problemas de compatibilidad entre versiones de hardware, e incluso los sistemas que priorizaban la compatibilidad no estaban libres de incompatibilidades.
  Incluso en Windows 11, que es el sistema moderno más inestable, mi computadora es mucho más estable que cualquier computadora que usé antes de 2010, y además puede ejecutar software para Windows 95.
  Una computadora que se puede usar a diario es mejor que una que no.

• No toda simplificación es una abstracción, y no toda abstracción es una simplificación.
  Pero muchas veces, al buscar simplificar, se termina creando una abstracción.
  No creo que la abstracción mate al software ni a la civilización, pero una mala abstracción creada con la excusa de una simplificación a corto plazo reduce la flexibilidad, la agilidad y la accesibilidad.
  Si uno mira el azúcar sintáctico de casi cualquier lenguaje, llega un punto en que la simplificación local que se obtiene en ese matiz específico no justifica el aumento de complejidad de toda la herramienta.
  En los lenguajes con mucha sintaxis, la gente se equivoca no por un elemento puntual, sino porque usar la herramienta para resolver bien problemas complejos se vuelve difícil en sí mismo.
  La complejidad que async y las corrutinas en Kotlin agregan a mi experiencia al manejar código “parecido a hilos” es totalmente distinta de la forma en que Elixir/Erlang aborda el mismo tipo de problema.
  Ambos ofrecen abstracciones y simplificaciones para el viejo problema del cómputo paralelo y asíncrono, pero el primero multiplica varias capas de simplicidad hasta volver a crear algo complejo, mientras que el segundo se parece más a una abstracción realmente simple que simplemente funciona.

• El autor parece pertenecer a una generación más joven, y por eso da la impresión de que no entendió el punto de Blow.
  Irónicamente, el propio texto parece un ejemplo de lo que Blow señalaba.
  Es parecido a decir que Figma está arruinando el mundo del diseño a una escala sin precedentes al normalizar la mala UX, UI y gestión de producto de Figma, y recibir como respuesta a diseñadores jóvenes desconcertados diciendo que todo está bien.
  Ese conocimiento existe porque uno creció en ese entorno, ellos no, y tampoco es fácil aprender en otro lado lo que corresponde a cultura y experiencia.

  • ¿La refutación al final es “es joven e inexperto, por eso está equivocado”? Puede ser, pero falta decir exactamente en qué se equivoca.
    Este tipo de ataque ad hominem no aporta nada a la conversación.
  • ¿Podrías explicar más cómo Figma está arruinando el mundo del diseño?
  • ¿Qué punto crees que se le escapó al autor?
  • No me da para nada la impresión de que el autor sea de una generación más joven. El resto tampoco es cierto.
  • El argumento de Blow ya fue bien refutado, así que no hace falta sacar el tema de la edad, pero el autor parece tener al menos unos 40 y tantos años. La Amiga fue popular a fines de los 80.
    A diferencia de la afirmación de que “la idea de que el software está progresando es manifiestamente falsa”, todavía uso con frecuencia las computadoras Amiga que tanto quiero.
    Hace unas semanas, mientras copiaba archivos al disco duro de una Amiga, la computadora se colgó de repente, no porque yo hubiera hecho algo mal, sino porque los sistemas operativos de las computadoras domésticas antiguas no eran muy estables.
    Como resultado, se dañó la partición del disco duro, el sistema operativo no pudo volver a validar el sistema de archivos y al final no quedó otra que reformatear la partición.
    No sé mucho de diseño, pero sí puedo ver que la afirmación sobre Figma, igual que la de Blow, está completamente equivocada.
    Eso es la nostalgia hablando. Las interfaces de usuario siempre tuvieron un montón de desastres, y lo mismo pasa con el software y con todo lo demás.
    Solo se recuerdan las virtudes de los mejores ejemplos del pasado, y se olvidan tanto la basura como incluso los fracasos de las cosas bien diseñadas.

• El problema son las abstracciones que no se pensaron a fondo.
  Muchas abstracciones dejan ver que son un primer borrador o un primer intento, pero por el culto a la velocidad y la arrogancia de la industria tecnológica se lanzan tal cual antes de refinarlas varias veces.
  Cuando esas abstracciones pasan a formar parte de proyectos populares, otros las copian por imitación bajo la bandera difusa de las “mejores prácticas”.
  Si se repite este proceso durante 10 o 20 años, se crea un desastre enorme.
  Peor aún, en una sociedad paradójicamente sobresocializada por la tecnología, el consenso social de no querer quedar expuesto como “impostor” sigue propagando soluciones inmaduras.
  Me gusta esa charla de Jonathan Blow y la vuelvo a ver al menos una vez al año. Creo que él no dice cosas polémicas, sino que muchos desarrolladores se enojan o se sienten tocados porque en el fondo saben que no lanzan lo mejor que podrían ni guían bien a las generaciones más jóvenes.
  Llegamos a una cultura en la que la búsqueda de lo nuevo es cotidiana y a veces incluso celebrada.
  Antes, las soluciones suficientemente revisadas eran el estándar cultural; ahora lo nuevo se volvió el estándar, independientemente de si realmente es bueno.
  Se pueden diseccionar interminablemente los detalles del argumento de Blow, pero la evidencia está a la vista por todas partes.
  Y en una escala temporal suficientemente larga, eso puede llevar al colapso de la civilización; viendo la cantidad de cosas rotas en el mundo, también podría decirse que ya está ocurriendo.

• Es una lástima que haya que desarmar con tanto detalle una tesis defectuosa.
  Un empirista puro está tan alejado de la realidad como un teórico puro, y Blow construye argumentos solo porque encajan con su propia experiencia, eligiendo únicamente ejemplos que se ajustan a sus quejas y presentando excepciones como si fueran reglas.