Hacia un software comprensible

• La programación es difícil de leer, probar y mantener, y la comprensión de los proyectos suele concentrarse en pocas personas; por eso, más que automatizar la escritura de código con LLM, hacen falta abstracciones que reduzcan el alcance mismo en el que se necesita código.
• Aunque los LLM se han extendido tanto entre desarrolladores como entre no desarrolladores, siguen teniendo grandes problemas, como su impacto ambiental destructivo, su base en código robado, resultados inconsistentes y generación de dependencia.
• El punto de partida es invertir la práctica de escribir primero el código y agregar documentación después, para pasar a una programación literaria en la que se escribe primero la documentación y el código viene después.
• La programación visual basada en GUI y la programación en lenguaje natural determinista pueden hacer que el código sea solo una de varias representaciones, pero en los entornos visuales es indispensable diseñar accesibilidad, como una integración con lectores de pantalla.
• Intentos previos como Eve e Inform, y herramientas como Entangled y ReTangled, muestran la posibilidad de crear software de una manera comprensible tanto para principiantes como para expertos.

---

Los LLM no son el modelo objetivo

• Los LLM se han convertido en herramientas importantes en el desarrollo de software industrial, y hasta especialistas con mucha experiencia usan agentes LLM para pruebas, depuración y escritura de código.
• Personas que no son desarrolladoras también están usando LLM para crear desde scripts personales hasta herramientas de procesamiento de datos científicos.
  • La programación tiene un punto de partida poco claro y es poco accesible para quienes no quieren aprender la sintaxis de un lenguaje específico ni los detalles de sus bibliotecas.
• La expansión de los LLM no es tanto una señal de que los LLM programen muy bien, sino de que programar en sí es una tarea compleja y desagradable.
  • Hay muchos stacks de software en conflicto, boilerplate interminable y bibliotecas difíciles de usar.
  • El trabajo promedio de un desarrollador de software se ha reducido más a pegar bibliotecas que a desarrollar código interesante.
• Los LLM todavía tienen problemas importantes.
  • Son ambientalmente destructivos.
  • Se basan de forma fundamental en código robado.
  • Generan código inconsistente.
  • Inducen dependencia.
• El paradigma actual de programación también es insuficiente, pero los LLM igualmente necesitan una alternativa mejor.

Abstraer en lugar de automatizar

• Renunciar a los LLM no significa tener que renunciar también a la automatización, a las abstracciones de alto nivel ni a las interfaces amigables para humanos.
• El objetivo no es detenerse en hacer más fácil escribir código, sino lidiar con el stack de software que hay debajo del código y reducir la necesidad misma de escribirlo.
• Si surge repetidamente el deseo de automatizar una capa de abstracción, lo más adecuado no es automatizar esa capa, sino abstraerla hasta eliminarla.
• El uso extendido de LLM en programación muestra el deseo de automatizar el proceso de escritura de código, y eso es una señal de que hay que abstraer la propia necesidad de escribir código.
• En vez de hacer que los humanos piensen como computadoras, se necesita una nueva capa de abstracción más cercana a la forma en que los humanos piensan naturalmente.

Programación con la documentación primero

• El primer paso hacia un software comprensible es la documentación.
  • Si se quiere que otras personas entiendan un software, hay que explicar ese software.
• La forma habitual es escribir primero el código y luego agregar doc-comments o ejemplos de uso.
• La propuesta es invertir el orden: escribir primero la documentación y después adjuntar el código.
  • Primero se le explica a una persona qué hace el programa, y después se le indica a la computadora qué debe hacer.
  • Este concepto se conoce como programación literaria.
• Con este enfoque, en lugar de leer directamente el código de otra persona e inferir su intención, primero se lee la documentación para entender la intención y luego se revisa el código.
• Entangled es una buena implementación de este enfoque.
  • Es un tangler bidireccional que extrae código desde la documentación y lo coloca en los archivos de código fuente correspondientes.
  • Los bloques de código dentro de la documentación se pueden editar, y los cambios hechos en archivos de código normales también se propagan a los bloques de código de la documentación.
  • Las herramientas existentes, como pruebas, refactorización y formateo de código, pueden seguir usándose sin soporte especial para programación literaria.
  • El tangler agrega poca sobrecarga al sistema de build, especialmente pequeña en comparación con el compilador.
• Este enfoque no elimina la complejidad del código en sí, pero puede reemplazar a los LLM en el ámbito de entender el código de otras personas.

Eliminar código: GUI y múltiples representaciones

• El código es un concepto de una época antigua, una forma que se ha usado porque había que interactuar con la computadora a través de la terminal.
• Aunque la computación cambió durante los últimos 40 años, no hay razón para insistir en que debamos comunicarnos con las computadoras solo mediante cadenas unidimensionales de símbolos y palabras clave ambiguas.
• Las GUI suelen facilitar el manejo de conceptos complejos en comparación con las interfaces basadas en texto, y muchas veces son más accesibles para usuarios nuevos.
• Un IDE puede ser más que un lugar cómodo para editar código: puede convertirse en una nueva forma de interactuar con el desarrollo de software.
  • Algunos IDE ya ofrecen funciones de este tipo.
  • Más aún, la programación visual podría volverse lo suficientemente general y simple como para que cualquiera cree lo que quiera sin aprender código.
• No hace falta abandonar por completo el código en sí.
  • Una representación GUI puede ser una de varias representaciones editables por personas.
  • Así como hay quienes prefieren interfaces de sistema operativo basadas en texto, también puede seguir habiendo quienes prefieran editar software mediante código.
  • Sin embargo, el código no tiene por qué ser el valor predeterminado ni la única opción.
• La programación visual puede diseñarse para ser más accesible, pero los entornos centrados en lo visual pueden llevar a la exclusión de personas ciegas.
  • Se necesita una integración sólida con lectores de pantalla.
  • También hacen falta representaciones alternativas que puedan entenderse de forma rica mediante audio o tacto.

Convertir el lenguaje natural en una abstracción determinista

• A diferencia de la idea de que los LLM suben un nivel la abstracción, los LLM se parecen más a una capa de automatización que a una abstracción.
• Una capa de abstracción debe ser predecible y confiable, y una intención de alto nivel debe expresarse de forma exacta y consistente en un nivel más bajo.
• Los LLM interpretan prompts de manera probabilística y predicen la intención, por lo que se comportan de forma impredecible.
  • Automatizan el proceso de aproximar aleatoriamente el resultado de una tarea.
  • Si fueran una abstracción, serían una abstracción con muchísima pérdida.
• Los avances en procesamiento de lenguaje natural (NLP) ofrecen la posibilidad de crear un pipeline predecible del lenguaje natural al lenguaje máquina.
• El objetivo es escribir entradas como si fueran prompts para LLM, pero crear programas predecibles y robustos cada vez.
  • Sin destilar el trabajo de otras personas como un promedio de código robado, sino construyéndolo directamente mediante definiciones.
• Este enfoque puede unir con más fuerza la documentación y el código.
  • Si en la programación literaria se reemplazan las partes de código por lenguaje natural, podría quedar solo la documentación.
  • El texto que explica a las personas cómo funciona un programa podría ser, al mismo tiempo, el texto que se comunica con la máquina.
• Esta programación en lenguaje natural debe ser determinista.
  • El NLP puede usarse para parsear de la gramática al significado sin la capacidad generativa de los modelos transformer.
  • La gramática parseada puede convertirse directamente en una representación intermedia que se compile según los requisitos de la plataforma, como en otros lenguajes de programación.
• Se imagina algo parecido a Inform, pero con mayor reconocimiento sintáctico y conectado a una red de definiciones más amplia.
• Gracias a su cualidad determinista, los prompts se convierten en código de forma confiable y consistente; esto es una verdadera capa de abstracción fundamentalmente distinta de los LLM.

Intentos anteriores: Eve e Inform

• Estas ideas no son nuevas; antes ya hubo intentos de implementarlas.
• Eve fue un lenguaje de programación y un IDE que buscaban hacer la programación más accesible para los humanos.
  • Usaba un enfoque de programación literaria.
  • Insertaba un lenguaje de programación orientado a datos y específico de dominio dentro de documentos que describían el comportamiento del software.
  • El código dependía de la documentación, y todo el entorno de programación reflejaba eso.
• Eve también intentó expandir más esta idea reemplazando su propio lenguaje por consultas NLP.
  • No estaba preparado para manejar la complejidad del procesamiento de lenguaje natural.
  • En 2016, el NLP más avanzado no era fácilmente accesible para una empresa que no estuviera centrada en machine learning.
  • También experimentó con un enfoque orientado a GUI.
• Un excolaborador de Eve también aborda preocupaciones similares sobre la complejidad del proyecto y las limitaciones de los LLM.
• Eve terminó porque era un proyecto ambicioso con inversión de VC que no logró monetizar, y no hubo oportunidad de ver cómo sus ideas daban fruto.
• Inform es un lenguaje declarativo para crear ficción interactiva, y muestra que estos conceptos pueden aplicarse de forma más amplia.
• Es posible que el lenguaje natural sea, en el fondo, una abstracción con fugas, pero su potencial para permitir que una persona promedio controle directamente su computadora merece más atención.

Próximos pasos y trabajo propuesto

• Se está desarrollando ReTangled como proyecto para crear software comprensible.
  • Es un tangler bidireccional compatible con Entangled, escrito en Rust.
  • Su objetivo es extender la programación literaria tanto como sea posible e integrarse de forma razonablemente estrecha con las toolchains existentes.
  • Actualmente está en una etapa temprana de desarrollo y se aceptan contribuciones.
• Hay planes de escribir textos más completos sobre programación visual, programación literaria y programación en lenguaje natural por separado.
• A nivel comunitario, se propone seguir los pasos de Eve, pero con un enfoque ligeramente diferente.
• El objetivo es crear un entorno de programación visual o en lenguaje natural bien documentado y accesible, útil desde principiantes hasta expertos.
• El punto de partida es documentar mejor el software, y el objetivo final es darle vuelta al concepto mismo de programación.

[GN⁺]

Comentarios en Lobste.rs

• No estoy seguro de que tirar el código a la basura o subordinarlo a prosa en lenguaje natural sea una solución eficaz al problema de accesibilidad de la programación.
  Los lenguajes de programación son una interfaz de usuario que equilibra las necesidades de las computadoras y de los humanos. Una notación formal bien hecha y clara puede ser una herramienta para pensar que ayuda a la comprensión individual y a transmitir ideas entre personas y máquinas.
  Aprender lenguajes de la familia APL me influyó mucho y, aunque me tomó tiempo dominarlos, una vez aprendidos pude mantener problemas más grandes en la cabeza y pensar con más precisión. Con K se pueden resolver problemas solo con la mente, papel y un REPL simple, sin un IDE complejo.
  Los proyectos bien documentados y la programación literaria tienen valor, pero la documentación también lleva tiempo para leerla, escribirla y corregirla. Al igual que con las pruebas, más documentación no es automáticamente mejor; prefiero explicaciones concisas y estructuradas, y programas concisos que sean fáciles de explicar. El código puede ser poesía, pero la mayoría de la poesía no es un programa.

  • Me gusta la programación formal, pero no creo que el usuario promedio tenga que convertirse en programador para aprovechar el poder de la computadora.
    La mayoría de la gente no va a aprender estos mecanismos internos, así que quiero bajar la barrera de entrada para que más personas puedan participar.
    Por eso creo que los LLM son populares. A menudo veo a no programadores escribir código con LLM para resolver tareas, pero como decía el artículo, los LLM tienen defectos importantes que quisiera evitar. La gente debería poder modificar juegos, crear scripts y ampliar programas con lenguaje natural o con interfaces de usuario cómodas.
    La frase “abolir el código” quizá fue un poco exagerada, pero mucha gente no quiere pensar en código, y tampoco debería tener que hacerlo.

• Los programadores, en la práctica, dejaron abandonados a los no programadores.
  Visual Basic murió, PHP sin frameworks tampoco parece muy activo, y Access prácticamente murió. Quedan herramientas parecidas a bases de datos como Notion o Airtable.
  Los programadores aman tanto escribir código que muchos se alejaron de las soluciones simples para problemas simples.
  Python en su momento arrasó en el mundo de los no programadores porque parecía simple, y herramientas como Pandas también parecían fáciles de usar. Curiosamente, muchos programadores no tienen muy buena opinión de Python o Pandas. Por ejemplo, cuando uno ve código que usa Pandas para hacer algo que se podría hacer fácilmente con la biblioteca estándar, termina bastante harto.
  Antes, incluso los no programadores creaban páginas HTML y les ponían colores e imágenes. Hoy, si le pides a un programador que haga un sitio web estático, viene acompañado de una complejidad absurda. Parte de ella es necesaria, pero la mayoría no lo es en absoluto. Si a un no programador le das el procedimiento que usan los programadores para crear un sitio web simple, incluso quienes hace 20 años habrían disfrutado editar HTML saldrían corriendo a los gritos.
  Es profundamente irónico e inquietante que hoy haya cosas que, de hecho, se volvieron mucho más difíciles.

  • Eso no tiene ningún sentido. Hoy cualquiera puede escribir HTML, y de hecho es más fácil que antes.
    CSS se volvió más potente, los navegadores están menos rotos y también hay asistentes personales de código que ayudan con todo. Con Python puro pasa lo mismo: simplemente lo usas. Programar nunca fue tan fácil.
    La complejidad de los stacks tecnológicos modernos suele tener una razón, pero hay que usarlos después de que exista esa razón; un principiante no tiene ninguna necesidad de usarlos.
    Si la gente no crea sitios web HTML o programas básicos, es porque no quiere hacerlo. Pensábamos que en el futuro todo el mundo sabría programación básica, pero en realidad quedó claro que la gente simplemente no quiere. También se podría argumentar que todos deberían saber hacer mantenimiento básico de autos o bicicletas, pero la gente se resiste. Eso no significa que la tarea sea difícil o imposible, sino más bien que no hay voluntad de hacerla.
    Creo que la alfabetización informática del público general casi no avanzó, y no tiene relación con la complejidad de la programación. En el ámbito educativo incluso se dice que la alfabetización informática parece estar retrocediendo, y es difícil atribuir eso a frameworks de frontend complejos.

• Estoy de acuerdo con muchas partes del artículo. Por ejemplo, me gusta la programación literaria, pero no creo que programar en sí sea malo.
  Parte de la programación es mala, y la programación que se hace en empresas BigTech suele ser mala en general. Pero escribir programas para mí o para las personas que quiero sigue siendo algo disfrutable.
  No conocía Entangled, pero parece una buena idea y aborda el mayor dolor de la programación literaria: el problema de la falta de reconocimiento por parte de LSP y las herramientas existentes. Por eso, hasta ahora he usado programación literaria sobre todo con lenguajes declarativos, como configuraciones de NixOS.
  Con programación literaria bidireccional, la vida podría volverse más fácil al usar lenguajes no declarativos. Pienso probar ReTangled.

  • Programar no es malo. Hasta esa frase estaba de acuerdo con el autor, pero cuando apareció lo de “aceptemos las GUI”, se me fue el interés.
    Las GUI parecen existir principalmente para que los ejecutivos y cargos superiores crean que sus empleados están haciendo cosas que ellos pueden entender y hacer.
    Tomé una clase sobre una herramienta ETL visual de arrastrar y soltar, y solo me quedó la impresión de que sería difícil volver a crear algo casi igual al primer sistema y también difícil versionar todo el conjunto. En 2010, el sistema visual de arrastrar y soltar que reemplazaba a cron y que usaba mi empresa de entonces era parecido.
    Para los ejecutivos es fácil arrastrar y soltar, pero para quienes hacen el trabajo se vuelve difícil encontrar errores, mantener versiones y respaldos, y reutilizar cosas.
  • Si esa función es el objetivo principal, recomendaría usar Entangled hasta que stitching funcione en ReTangled.
  • Hay un tramo realmente duro en el proceso de llevar algo que es divertido de usar en el momento hasta convertirlo en algo que al usuario le pueda gustar.
    Para convertir un prototipo divertido en algo apto para producción, hace falta mucho manejo de errores, serialización, deserialización, proyecciones de tipos, etc. Una de mis reglas es que una gran experiencia de usuario casi siempre implica una estructura interna desordenada.
    Personalmente, no disfruto la mayor parte de eso, y en el pasado a veces tomé atajos o directamente no hice ese trabajo.

• Estoy bastante de acuerdo. Si miramos los editores WYSIWYG, no reemplazaron por completo el desarrollo web, pero sí redujeron bastante el nicho de personas que solo querían un sitio web básico o vender productos simples.
  Todavía hay muchas áreas de software que podrían simplificarse con una buena interfaz GUI.
  Si ahora estás simplemente pegando código o usando LLMs a lo loco, quizá en realidad te convendría más la programación con GUI. Gran parte del código que uso con frecuencia también suele ser un servidor REST, y no veo por qué no se podría crear algo para eso.

• Compartimos el mismo objetivo, y llevo años pensando en un stack tecnológico que ofrezca exactamente la solución que quiero usar.
  Publiqué un proyecto llamado Curv, pero es solo una pequeña parte de un sistema mucho más bello que aún solo existe en mi cabeza.
  Miles de otras personas también se han dedicado a este problema. Por su tamaño, parece requerir trabajo en equipo, pero en la práctica casi todo son pequeños proyectos de una sola persona. Muchas veces, quienes tienen la visión más fuerte no quieren comprometerla por los objetivos de un equipo. No sé cómo resolver eso.
  Entre los proyectos inspiradores están la visión Dynabook de Alan Kay, Smalltalk que surgió de ahí, el proyecto posterior de Alan Kay STEPS Toward the Reinvention of Programming, el trabajo de Bret Victor y, en especial, su logro asombroso: Dynamicland.
  Una comunidad interesada en este tema es Feeling of Computing, antes llamada Future of Coding. Si conocen otras para agregar, me gustaría saberlo.

• La idea de “ingresar instrucciones como en un prompt para un LLM y crear un programa completo, pero que funcione de forma predecible y robusta cada vez” se basa en una suposición enorme: que se puede parsear desde el lenguaje natural una semántica determinista y coherente.
  Pero, para empezar, no creo que eso sea cierto. Incluso dejando de lado que todavía nadie lo ha hecho funcionar bien, dudo que sea posible.
  El lenguaje tiene demasiado contexto. Puedes decir la misma frase doce veces y, según la entonación, el público, la ubicación física, el medio por el que se dice y la hora del día, cada vez tendrá un matiz distinto. Las técnicas tradicionales de procesamiento de lenguaje natural no pueden manejar de raíz esa flexibilidad.
  Precisamente por eso existen los LLMs. En vez de intentar definir reglas estrictas de contexto que quizá ni existan, se entrena un modelo capaz de codificar la detección de contexto en sus pesos. Y resultó ser sorprendentemente eficaz.
  Por eso la gente usa LLMs. Porque pueden considerar el contexto mucho mejor que cualquier otra interfaz de lenguaje natural creada hasta ahora y generar la respuesta esperada. Desde ese punto de vista, realmente funcionan. El procesamiento de lenguaje natural fuera de los LLMs no ha mostrado el mismo nivel de éxito.

• Si te interesan los entornos visuales de programación ricos, Glamorous Toolkit es un buen ejemplo de una posible dirección: https://gtoolkit.com/
  No diría que ya sea una forma finalizada, pero es una herramienta que lleva más lejos lo que ya existía. En la era del código generado por LLMs, también vale la pena hablar de entornos basados en imágenes.

  • Revisé por encima el sitio web de Glamorous Toolkit y no entendí en absoluto qué es. ¿Podrías resumirlo en unas pocas frases?

• Lo que falta son abstracciones predecibles más allá de los elementos primitivos que los programadores suelen usar hoy: líneas de código organizadas en funciones y módulos.
  En particular, cuando los requisitos no son simples transformaciones de datos sino el modelado de sistemas externos complejos, trasladarlos solo a esos elementos termina convirtiéndose en una bola de lodo cada vez más grande, incluso si lo hacen programadores humanos. Los LLMs están imitando esa misma forma.