- La postura que culpa de la dificultad de programar a los símbolos formales genera la falsa expectativa de que, si la máquina entendiera lenguaje natural, la carga humana disminuiría
- El peligro del lenguaje máquina inicial se alivió en parte con los lenguajes de programación de alto nivel, pero la esencia sigue intacta: las respuestas equivocadas solo se convirtieron en mensajes de error y sigue siendo necesario dar instrucciones precisas
- Las interfaces en lenguaje natural no son una solución para repartir el trabajo, sino que pueden aumentar el costo de cooperación y comunicación entre humanos y máquinas, incrementando la carga para ambos lados
- La evolución de las matemáticas muestra que los sistemas de símbolos formales creados por figuras como Vieta, Descartes, Leibniz y Boole fueron herramientas clave para manejar pensamientos complejos
- Si la programación en lenguaje natural se hubiera adoptado como entrada y salida básica, es muy probable que las ciencias de la computación hubieran terminado siendo un largo rodeo para volver a sistemas formales utilizables
Expectativas y malentendidos en torno a la programación en lenguaje natural
- Desde los inicios del cálculo automático, algunas personas consideraban un defecto que programar exigiera la atención y precisión requeridas por los símbolos formales
- Veían como problema que la máquina ejecutara estrictamente incluso instrucciones erróneas, y esperaban una máquina más “sensata” que rechazara errores administrativos triviales
- El lenguaje máquina casi no tenía redundancia, por lo que era una interfaz peligrosa entre humanos y máquinas
- Como respuesta, se desarrollaron lenguajes de programación de alto nivel
- Con el tiempo hubo mejoras que hicieron que muchos errores menores terminaran en mensajes de error en vez de respuestas equivocadas
- Sin embargo, la máquina abstracta correspondiente al lenguaje de programación sigue siendo un autómata que ejecuta fielmente las instrucciones dadas, y todavía puede ejecutar instrucciones sin sentido
- La propuesta de dar instrucciones a la máquina en lenguaje natural se apoya en la lógica de que, aunque la máquina se vuelva más compleja, la carga humana podría reducirse
- Esa lógica solo parece plausible si se considera que la causa de la dificultad es la “obligación de usar símbolos formales”
- Cambiar la interfaz no consiste simplemente en repartir el trabajo, sino en añadir costos de cooperación y comunicación a través de la interfaz
- Empíricamente, cambiar la interfaz puede aumentar mucho la carga de trabajo de ambos lados, y por eso crece la preferencia por una “interfaz estrecha”
Cómo los símbolos formales amplían el pensamiento
- En la historia de las matemáticas, los enfoques centrados en el lenguaje natural y en lo visual han mostrado sus límites una y otra vez
- Las matemáticas griegas se estancaron al permanecer en actividades lingüísticas y diagramáticas
- El “algebra” musulmán intentó brevemente usar símbolos, pero volvió al estilo retórico y desapareció
- Europa occidental salió de los intentos medievales de precisión lingüística del escolasticismo gracias a los símbolos formales diseñados conscientemente por figuras como Vieta, Descartes, Leibniz y luego Boole
- La ventaja del texto formal es que una manipulación válida solo necesita cumplir unas pocas reglas simples
- Esa regularidad sirve como herramienta para excluir varios tipos de falta de sentido que en el lenguaje natural son difíciles de evitar
- Usar símbolos formales no es una carga, sino casi un privilegio
- Gracias a ellos, estudiantes pueden aprender tareas que antes solo estaban al alcance de genios
- La frase de un prólogo de un informe técnico de 1977, “por claridad se evitó incluso la notación estándar de los conectores lógicos”, muestra que este malentendido no se limita a una sola persona
- La “naturalidad” del lenguaje natural lleva a que sea fácil crear oraciones cuyo sinsentido no resulta evidente
Las ciencias de la computación en un mundo donde solo se permite el lenguaje natural
- Si desde el principio la entrada y salida de los equipos de procesamiento de información se hubiera hecho solo en la lengua materna, las ciencias de la computación habrían sido algo cercano a una “black art” para avanzar hacia sistemas formales suficientemente definidos
- Habría hecho falta la inteligencia del mundo entero para estrechar la interfaz hasta un nivel utilizable
- Considerando la historia de la humanidad, quizá habría tomado otros miles de años
- También se añade la preocupación de que la evolución educativa de Occidente se ha alejado del entrenamiento intelectual y ha deteriorado mucho la capacidad de las personas para manejar su propio idioma
- Se citan como ejemplo artículos científicos, informes técnicos y publicaciones gubernamentales que, al leerse con cuidado, contienen muchas palabras sin sentido
- A este fenómeno se le llama “The New Illiteracy”, y sirve de advertencia incluso para los partidarios que no tienen la visión técnica para prever el fracaso de la programación en lenguaje natural
- Se cierra con la sospecha de que una máquina programada en lenguaje natural sería tan difícil de usar como de construir, ya sea que emplee Dutch, English, American, French, German o Swahili
1 comentarios
Opiniones de Hacker News
Está bien defender a los LLM aquí, pero me pregunto qué pasaría si lo hiciéramos al revés. Tomar un proyecto de complejidad media y usar tu LLM favorito para volver a convertir el código en lenguaje natural.
¿Podría explicar razonablemente el comportamiento y los requisitos contenidos en el código fuente, sin perder los detalles suficientes como para poder reproducir el programa? ¿Sería más fácil razonar a partir de esa descripción en lenguaje natural?
Creo que hay una razón por la que las apps de vibe coding que muestra la gente suelen ser simples. Hay un nivel en el que la complejidad y la precisión se vuelven difíciles de manejar, y aunque se puedan definir en inglés llano, me pregunto si esa descripción es más explicativa que un lenguaje escalable, comprensible y preciso.
También creo que la razón por la que los documentos legales no están en inglés llano va más allá de simplemente crear una barrera de entrada.
METAR YSSY 031000Z 08005KT CAVOK 22/13 Q1012 RMK RF00.0/000.0.Casi sin excepción, los pilotos nuevos preguntan: “¿por qué no lo escriben con palabras?”, y de hecho la mayoría de las apps de planificación de vuelo convierten ese código en prosa.
Pero los pilotos profesionales y los controladores prefieren mucho más el formato codificado. Como es una sola línea, es compacto; el formato está bien definido, así que sabes exactamente dónde buscar los elementos que necesitas, y es inequívoco y claro.
Con las matemáticas y la programación pasa lo mismo: una vez que alcanzas cierto nivel de experiencia, la complejidad y la redundancia del lenguaje natural cuestan más de lo que aportan. Parece aplicarse a todos los campos profesionales.
Recuperar información desde la prosa toma mucho tiempo, y quienes leen textos largos empiezan a subrayar, tomar notas y crear sus propias abreviaturas.
Los formatos comprimidos y las abstracciones reducen la carga sobre la memoria de trabajo y la búsqueda de información. Así que puede que no sea solo un problema de precisión del lenguaje.
Uno pensaría que para pasar de esa frase a una app funcional hacen falta montones de detalles de implementación, pero con solo esa cantidad de información existe la posibilidad de llegar a una aplicación funcional que resuelva mi necesidad.
Y si con eso se puede construir lo suficiente, también se vuelven fáciles pedidos como “¿puedes cambiarlo a azul aciano?”, y el usuario puede iterar desde ahí.
Si solo le das a un LLM una ISA y un controlador de pantalla y le pides que haga una app gráfica en ensamblador, no vas a obtener nada.
Pero si hay montañas de abstracciones apiladas, probablemente sí sea posible.
No estoy intentando defender a los LLM; lo que digo es que, si proporcionas las abstracciones correctas y componentes reutilizables, puedes acercarte mucho más.
Me viene a la mente una cita antigua de Hal Abelson:
“Bajo nuestro enfoque de este tema está la convicción de que la ‘ciencia de la computación’ no es una ciencia, y que su importancia tiene poco que ver con las computadoras. La revolución informática es una revolución en la forma en que pensamos y en la forma en que expresamos lo que pensamos. La esencia de este cambio es la aparición de algo que podría llamarse más apropiadamente epistemología procedural: el estudio de la estructura del conocimiento desde un punto de vista imperativo, a diferencia del punto de vista más declarativo adoptado por las áreas clásicas de las matemáticas. Las matemáticas proporcionan un marco para tratar con precisión las nociones de ‘qué es’. La computación proporciona un marco para tratar con precisión las nociones de ‘cómo hacerlo’.”
Por más demos impresionantes y declaraciones de “la IA mató la programación” que haya, gran parte del trabajo real se traslada al preprocesamiento, posprocesamiento y evaluación alrededor de la IA.
Es bueno en cuanto a hacer la programación más accesible, pero no puede reemplazar realmente a la programación.
Por fin alguien lo expresó así. El lenguaje natural tiene límites inherentes que surgen de las limitaciones mentales humanas. La mente humana a veces piensa de forma demasiado abstracta o demasiado concreta, y pasa por alto detalles importantes o generalizaciones.
Como programador, lo he sentido directamente: los problemas, o incluso los absurdos, de una tarea muchas veces no se revelan hasta que empiezas a implementarla como código, es decir, en un sistema simbólico estricto.
Además, muchas veces explicar algo con precisión en lenguaje natural toma más tiempo que simplemente escribir el algoritmo en código.
¿Con qué frecuencia reescribimos una frase, decimos “en realidad, lo que quería decir era…”, o reformulamos un correo antes de enviarlo? Somos humanos y rara vez acertamos perfectamente al primer intento.
Ahora estamos convirtiendo el lenguaje natural, esta forma imperfecta de comunicación, en código: el lenguaje de máquinas famosas por hacer exactamente lo que se les dice, no lo que se quiso decir.
El procesamiento de lenguaje natural es tremendamente útil para encaminar en la dirección correcta la creación de apps o scripts. Pero al final puede que haga falta refactorizar varias partes.
No hace falta ser un experto en código para obtener valor de un LLM, pero aun así saber programar sigue ayudando, y a veces es necesario.
/s: Porque todavía no hemos ido lo suficientemente lejos. La gente genera programas de computadora en lenguaje natural, pero en su lugar debería ejecutar directamente los prompts
“Eres un sistema gráfico. Eres la entidad que administra lo que hay en la pantalla. Puedes recibir solicitudes de todos los programas para crear y eliminar ‘ventanas’, y también solicitudes adicionales para dibujar texto, líneas, círculos, etc. en ventanas creadas previamente. Los elementos pueden ser de cualquier color.
Además, debes enviar más información de clics a quien creó la ventana en la que el usuario hizo clic con el mouse.
El administrador de ventanas es un programa especial y puede decirte qué ventanas se muestran y dónde en todos los monitores conectados al sistema”
Y “Eres un programa de tres en raya. Hay un sistema gráfico que administra lo que hay en la pantalla. Puedes ordenarle a ese sistema que cree y elimine ‘ventanas’, y que dibuje texto, líneas, círculos, etc. en ventanas que creaste previamente. Los elementos pueden ser de cualquier color.
Los gráficos que dibujes deben mostrar una partida de tres en raya en la que el usuario avanza por turnos haciendo clic con el mouse. Si el usuario gana…
Agrega anuncios al juego, a menos que el usuario tenga una suscripción de pago por clic”
Con eso debería bastar para que el juego funcione
Para guardar, hace falta otro prompt. “Eres un sistema de archivos. Eres la entidad que persiste datos en el disco…”
Y también hace falta “Eres un sistema operativo multitarea. Les das a varios LLM la idea de que tienen control total de la CPU y la memoria del sistema. Tú…”
Espero ver esto a principios de abril del año que viene
“El lenguaje de máquina carece de redundancia en casi todas sus formas, por lo que pronto se lo reconoció como una interfaz innecesariamente peligrosa entre humanos y máquinas. En respuesta parcial a ese reconocimiento se desarrollaron los llamados ‘lenguajes de programación de alto nivel’, y con el tiempo aprendimos a reforzar en cierta medida la protección contra errores tontos. Fue una mejora importante que ahora muchos errores tontos terminaran en mensajes de error en lugar de respuestas incorrectas.”
Siento que, como colectivo, nos lanzamos demasiado rápido a la programación con LLM. Me gustó mucho cómo Rust ha ido evolucionando para señalar errores tontos y hacer mucho más claro cómo corregirlos
Como desarrollador, sigo teniendo el contexto y la comprensión del código en el que estoy trabajando, y el compilador me indica los errores obvios y cómo arreglarlos. En cambio, usar un LLM se siente como un juego de adivinanzas a medias inteligente
El compilador de Rust es un maestro que enseña a su aprendiz, mientras que un LLM se parece a un egresado seguro de sí mismo que corrige al maestro. Prefiero mucho más el enfoque de Rust y me gustaría que avanzara más si es posible
El lenguaje natural es un medio pobre para transmitir reglas y órdenes. La situación actual de Estados Unidos es un buen ejemplo
Todavía discutimos qué significan ciertas leyes y enmiendas constitucionales. El significado de las palabras cambia con el tiempo, y también se pierde contexto histórico
Sería bueno poder manipular máquinas en lenguaje natural, pero como alguien que programa desde mediados de los 80, creo que la rigidez de los lenguajes de computadora, de BASIC a Go, logra un buen equilibrio. Hace que quien da las órdenes asuma suficiente responsabilidad para expresar con precisión qué debe hacer la máquina
No estoy del todo de acuerdo con este argumento. En las empresas reales, una idea para una nueva función muchas veces empieza en la cabeza de alguien del área de negocio. Esa persona no va a hablar ningún lenguaje formal
Por lo tanto, se mire como se mire, para implementar una función hace falta traducir de lenguaje natural a lenguaje de máquina
Normalmente, el primer paso, la traducción de lenguaje natural a lenguaje formal, lo hacen analistas de negocio y programadores. Entonces, ¿por qué no recibir ayuda de la computadora en ese proceso?
Por eso no solo refuta la idea de que los programas deban especificarse en lenguaje natural, sino también la idea de que eliminar la necesidad de entender lenguajes formales aumente nuestra capacidad de construir sistemas complejos
Mucha “traducción” en realidad no es traducción, sino corregir ambigüedades lógicas, inconsistencias y supuestos incorrectos. Si tomamos en serio a Dijkstra, buena parte de eso también puede hacerse dentro del lenguaje natural. Porque ahí hay programadores que se han dedicado toda la vida a formalizar
Hay otras profesiones que también requieren bastante pensamiento formal, como las matemáticas. Además, al convertir demostraciones antiguas en demostraciones por computadora, se han encontrado agujeros y lagunas en muchas demostraciones ampliamente aceptadas
No se han derribado muchas, pero todavía no tenemos una demostración completa del último teorema de Fermat https://xenaproject.wordpress.com/2024/12/11/fermats-last-th...
Si no piensas dentro de un sistema formal, tus ideas empeoran. Porque no tratas tus propios pensamientos como algo formal
Sobre cómo traducir la idea del “responsable de negocio” del ejemplo, probablemente no tendría mucho que decir. Desde su punto de vista, la idea del responsable de negocio ya es superficial y mala porque no sigue el formalismo, y por lo tanto no vale la pena traducirla
Si haces que “la computadora ayude en el medio”, pronto te topas con el problema de que, para obtener resultados suficientemente buenos de la máquina, necesitas un lenguaje natural cada vez más formal
Aunque no esté tan formalizado como un lenguaje de programación, claramente existe
Si intentas definir cualquier proceso, aunque no seas consciente de ello, al final tiendes hacia la formalización
“Fue una mejora importante que muchos errores tontos terminaran en mensajes de error en lugar de respuestas incorrectas. Ni siquiera esa mejora le gustó a todo el mundo. Algunas personas consideraban que los mensajes de error que no podían ignorarse eran más irritantes que los resultados incorrectos, y al juzgar los méritos relativos de los lenguajes de programación todavía parecen equiparar la ‘facilidad de programar’ con la facilidad de cometer errores que no se descubren”.
Si no hubiera sabido quién lo escribió, habría parecido una frase dirigida de lleno contra la gente que odia Rust.
Después de usar durante un tiempo Scala, un lenguaje que permite expresar invariantes más fuertes mediante tipos que Rust, dejé de ver esa característica como una victoria clara en cualquier situación. Ya no pienso que “tipos más fuertes == siempre mejor”.
“No permitir errores” tiene un costo. Si el sistema de tipos es realmente estricto, el trabajo exploratorio se vuelve bastante difícil. Incluso puede impedir la iteración rápida.
Por un cambio pequeño, podrías tener que rediseñar la mitad del programa para volver a satisfacer el sistema de tipos.
Es un trade-off. Como todo lo demás. Es bueno para un producto final robusto, pero estorba para la experimentación rápida.
Alguien explicó bien este problema en el contexto de Rust y el desarrollo de videojuegos: https://loglog.games/blog/leaving-rust-gamedev/
Pero no es un problema limitado a Rust ni al desarrollo de videojuegos.
Parece que ciertos tipos de tontería trascienden las épocas.
Aquí, de lo que él habla es de lenguajes interpretados.
También es uno de esos matemáticos que ahora se llaman científicos de la computación, cuyos “algoritmos” son poco más que una reformulación de las matemáticas y no requieren dispositivos. Es alguien temperamentalmente hostil a la incómoda actividad de programar computadoras reales.
Especificar y crear una aplicación en lenguaje natural es bastante parecido a tener un documento de diseño de juego antes de empezar un prototipo de juego.
Pero una vez que implementas la mayor parte de lo que quieres, la implementación se vuelve la referencia, y normalmente terminas descartando el GDD porque se desalineó del juego real.
Insistir en que, con cada cambio, haya que leer el GDD, implementar la funcionalidad y luego volver a sincronizar el GDD es engorroso y en la práctica no funciona bien. Nunca he visto que eso ocurra.
Si algún día la IA/los LLM pueden codificar desde cero la próxima versión de Linux o Windows solo a partir de una serie de prompts, todas las premisas cambiarán; pero por ahora claramente no hemos llegado a eso, y no sé si llegaremos.
El lenguaje natural es bastante bueno para describir requisitos técnicos de sistemas complejos. Es decir, no tanto la implementación actual del código en sí, sino por qué se eligió la implementación actual en lugar de otras posibles.
Sirve para capturar no lo que hace el código, sino lo que debería hacer; en otras palabras, las partes faltantes que están en lugares como Jira, no en el repositorio.
Además, si todo el sistema pudiera describirse mediante reglas externas y esas reglas pudieran imponerse en toda la base de código, también podría ofrecer una mejor capacidad de refactorización.
Hemos usado lenguajes de programación porque son fáciles de usar en el contexto de la automatización y las computadoras y, francamente, antes de los LLM también eran la única forma.
Los lenguajes de programación dan falta de ambigüedad a escala local, pero en cuanto alguien copia y pega una parte del código, dejan de funcionar a escala global.
¿Puedes estar seguro de que ese fragmento es un programa correcto que respeta todas las restricciones de alto nivel que debería seguir? Si compila, será un programa que se ejecuta, pero la definición de ejecutar es bastante laxa. En C++, incluso un programa que destruye toda la memoria puede ejecutarse.