La idea de que los lenguajes de programación dinámicos y "densos" —como Clojure o J— son mucho más eficientes en tokens para los grandes modelos de lenguaje (LLMs) de lo que lo son lenguajes estáticos como Rust, C++ o Go lleva años circulando en blogs y respuestas de inteligencia artificial. Sin embargo, un nuevo análisis del ingeniero Dan Luu, publicado en su blog danluu.com, desmonta esa creencia con argumentos metodológicos y experimentos propios: cuando los problemas dejan de ser triviales, la supuesta ventaja de los lenguajes dinámicos se diluye e incluso se invierte en algunos escenarios.
La tesis popular se apoya principalmente en dos trabajos. El primero es un post de Martin Alderson que comparaba el coste en tokens de distintos lenguajes sobre problemas de Rosetta Code y concluía que existía una brecha significativa: C, el menos eficiente, usaba 2,6 veces más tokens que Clojure, el más eficiente. Alderson llevó el experimento más allá con el lenguaje de arrays J, que según sus mediciones sólo necesitaba 70 tokens de media, casi la mitad que Clojure. El segundo, el repositorio "ai-coding-lang-bench" del japonés Yusuke Endoh (mame), llegaba a conclusiones similares. Ambos textos se han convertido en referencia habitual: una búsqueda de Google sobre "dynamic vs static language token cost" devuelve un resumen generado por IA que afirma, sin matices, que los lenguajes dinámicos tienen un menor coste de tokens para LLMs porque omiten declaraciones de tipo explícitas.
Lu objeta que esos experimentos adolecen de problemas de diseño que sesgan los resultados. El primero usa tareas tan pequeñas que gran parte del trabajo consiste en imprimir una respuesta; al aumentar la complejidad, las enormes diferencias desaparecen, igual que ocurre con las pruebas de "modo cavernícola" en las que un estilo de codificación extremadamente críptico parecía batir a todos hasta que se evaluaron problemas reales. El segundo benchmark contiene, según Lu, fallos más sutiles pero determinantes: una de las pruebas ejecuta una ruta inexistente, lo que provoca que un agente cree un enlace simbólico a su propio ejecutable; ese enlace termina activándose en pruebas posteriores y distorsiona la puntuación del lenguaje Rust, cuyas ejecuciones se redirigen al binario de Go. Lu sospecha que las conclusiones sobre Rust derivan precisamente de este error.
Para comprobar la hipótesis, Lu diseñó su propia evaluación con el modelo GPT-5.6 Sol: pidió a varios agentes que implementaran un decodificador completo de zstd a partir del RFC y material relacionado, sin acceso a internet y sin mostrarles los tests. Es una tarea con superficie mucho mayor que las de los benchmarks anteriores. Los agentes trabajaron con dos niveles de esfuerzo, medio y "ultra", y los resultados se representaron en gráficos donde el eje X mide coste y el eje Y mide corrección.
A esfuerzo medio, los lenguajes dinámicos aparecen agrupados arriba y a la izquierda, igual que en la evaluación de Alderson, lo que podría llevar a reproducir su conclusión. Pero a esfuerzo ultra el panorama cambia: la ventaja se diluye, varios lenguajes estáticos quedan entre los mejores resultados y la brecha con los dinámicos se reduce hasta hacerse prácticamente indistinguible. Lu observa un patrón parecido cuando se sustituye el coste por tiempo de ejecución: ningún tipo de lenguaje domina al otro de forma consistente.
El hallazgo más llamativo es la caída del "supremacismo de lenguajes raros" como J. Si el argumento de la eficiencia en tokens fuese robusto, los lenguajes oscuros y densos deberían arrasar; sin embargo, en tareas de cierto tamaño su ventaja se evapora. Lu especula que esto se debe, en parte, a que los laboratorios de IA invierten mucho menos esfuerzo en generar datos sintéticos y entornos de refuerzo para lenguajes minoritarios, por lo que el modelo es sensiblemente peor en ellos.
Antes de mirar los resultados, Lu había registrado tres predicciones: con un 95% de confianza, que la afirmación global "dinámico > estático" no se sostendría; con un 60%, que los lenguajes estáticos serían algo mejores a esfuerzo ultra; y con un 98%, que la supuesta supremacía de J tampoco aguantaría. Las tres se cumplieron, lo que refuerza su argumento.
La conclusión práctica para desarrolladores y equipos que están eligiendo stacks para programar con asistencia de IA es clara: no merece la pena migrar a un lenguaje exótico por ahorrar tokens, y la diferencia entre lenguajes dinámicos y estáticos mainstream es mucho menor de lo que sugiere la literatura más citada. Para problemas reales y de cierta envergadura, la elección del lenguaje importa menos que la calidad del prompting, del andamiaje del agente y del proceso de revisión. Lu advierte, no obstante, que sus propias pruebas también tienen limitaciones y que ningún benchmark está libre de defectos; la investigación sobre qué lenguajes y qué estilos de código maximizan el rendimiento de los LLMs sigue siendo un campo abierto.
Por ahora, la evidencia apunta a que la eficiencia en tokens es una variable menor frente a la corrección, la mantenibilidad y la popularidad del lenguaje en el ecosistema de entrenamiento de los modelos.