Translate

miércoles, 9 de septiembre de 2026

Si una IA pudiera programar completamente sola, ¿qué lenguaje elegiría?


Durante décadas discutimos cuál es el mejor lenguaje de programación.

Java o C#.

Python o JavaScript.

Rust o C++.


Programación funcional u orientada a objetos.

Pero quizás estamos haciendo la pregunta equivocada.

Porque todos esos lenguajes tienen algo en común: fueron diseñados para nosotros.

Para humanos.


Un lenguaje de programación no solo existe para darle instrucciones a una computadora.

También existe para compensar nuestras limitaciones.

Necesitamos nombres descriptivos porque no podemos recordar todo.

Necesitamos archivos y carpetas porque tenemos que organizar mentalmente sistemas enormes.

Necesitamos sintaxis legible porque otro humano tendrá que entender nuestro código.

Queremos escribir menos porque nos cansamos, cometemos errores y tenemos un tiempo limitado.

Por eso discutimos sobre cosas como:


for (User user : users) {

    if (user.isActive()) {

        result.add(user);

    }

}


vs.


users.stream()

     .filter(User::isActive)

     .toList();


Pero una IA no tiene necesariamente esas mismas limitaciones.

Entonces aparece una pregunta interesante: Si una IA pudiera construir software completamente sola, ¿seguiría eligiendo Java, Python, Rust o cualquier otro lenguaje diseñado para humanos?

No estoy tan seguro.


Quizás elegiría algo más declarativo

Los lenguajes imperativos suelen obligarnos a describir cómo queremos hacer algo.

  • recorrer esta colección
  • por cada elemento
  • verificar esta condición
  • agregarlo al resultado


Pero quizás una IA preferiría expresar simplemente:

usuarios activos


O, de manera más formal:


result = { u ∈ users | u.active }



Y dejar que otro sistema decida:

  • qué algoritmo utilizar;
  • cómo paralelizarlo;
  • dónde ejecutarlo;
  • qué estructura de datos conviene;
  • si usar memoria, disco o una base de datos;
  • si compilarlo para CPU, GPU o WebAssembly.


Esta idea ya existe, en diferentes formas, en lenguajes como SQL, Prolog o Datalog.

  • Nosotros declaramos qué queremos.
  • El sistema decide cómo obtenerlo.
  • Para una IA, esa separación podría ser todavía más natural.


Una IA probablemente no tendría miedo a los tipos

Hay tecnologías que muchas veces evitamos porque son demasiado complejas para usar todos los días.

  • Tipos dependientes.
  • Pruebas formales.
  • Teoría de tipos.
  • Lenguajes como Idris, Agda o Lean.


Para un humano, escribir algo como esto puede parecer excesivo:


transfer :

    Account

    -> Account

    -> PositiveAmount

    -> ValidTransaction


Pero para una IA, ¿por qué sería un problema?

Quizás, al contrario, sería una ventaja.

Hoy solemos escribir software así:

código+ validaciones+ tests+ tests de integración+ documentación+ monitoreo

+ "esperemos que nadie rompa esto"


Una IA podría preferir expresar propiedades directamente:

El saldo nunca puede ser negativo.

Un usuario nunca puede acceder a un documento de otra organización.

Esta operación siempre libera el recurso.

Esta lista siempre está ordenada.


Y después construir una implementación que pueda demostrar que esas propiedades se cumplen.


No solo: "Todos los tests pasan".


Sino: "Esta propiedad no puede violarse dentro de este modelo".


Quizás elegiría algo entre Haskell, Idris, Prolog y Datalog

Si obligáramos a una IA a elegir entre los lenguajes que existen hoy, mi apuesta estaría lejos de los lenguajes más populares.


Probablemente miraría hacia ideas presentes en:

  • Haskell, por su composición y su modelo funcional.
  • Idris, por sus tipos dependientes.
  • Agda y Lean, por la verificación formal.
  • Prolog y Datalog, por la programación basada en reglas y relaciones.
  • Erlang, por su modelo de concurrencia y distribución.
  • Rust, cuando el rendimiento y el control fueran importantes.


Pero quizás tampoco elegiría uno.

Podría utilizar todos.

El lenguaje no tendría que ser también el lenguaje de ejecución

Hoy solemos elegir un lenguaje y aceptar sus consecuencias.


Elegiste Java: Entonces tu programa se ejecutará sobre la JVM.

Elegiste Rust: Compilarás código nativo.

Elegiste JavaScript: Terminarás en un navegador o en Node.


Pero una IA podría pensar de otra manera.

Primero define el problema: usuarios activos ordenados por fecha


Después genera la mejor implementación para cada contexto:

Backend crítico      → Rust

Servicio distribuido → Erlang

Consulta de datos    → SQL

Frontend             → WebAssembly

Procesamiento masivo → GPU



En ese escenario, Java, Rust o SQL ya no serían necesariamente el lenguaje en el que se piensa el software.

Serían simplemente targets.

El resultado final de una representación más abstracta.


Pero hay una posibilidad todavía más radical. Quizás una IA ni siquiera elegiría un lenguaje textual.


Nosotros pensamos en:

class User {

    String name;

}


Porque programamos escribiendo texto.

Pero una IA podría trabajar directamente sobre una representación interna.

  • Un grafo.
  • Un AST.
  • Un sistema de tipos.
  • Un conjunto de restricciones.


Algo conceptualmente parecido a esto:


Entity

 └── User

      ├── name : String

      └── organization : Organization



Rule

 └── User can access Document

      when same organization

      and permission = READ



El código fuente podría convertirse en algo secundario.

Una interfaz.

Una traducción.

Una forma de que los humanos podamos mirar lo que está pasando.


Quizás el problema nunca fue encontrar el mejor lenguaje

Quizás todos los lenguajes que usamos hoy son soluciones a un problema específico: ¿Cómo hacemos para que los humanos puedan construir software cada vez más complejo?


Pero si quitamos al humano del proceso de implementación, la pregunta cambia.

Ya no necesitamos optimizar para:

  • facilidad de escritura;
  • facilidad de aprendizaje;
  • cantidad de caracteres;
  • convenciones;
  • legibilidad;
  • onboarding;
  • documentación para otros desarrolladores.


Podemos optimizar para otras cosas:

  • correctitud;
  • verificabilidad;
  • rendimiento;
  • capacidad de transformación;
  • optimización automática;
  • adaptación a diferentes plataformas.


Y entonces quizás el lenguaje ideal para una IA sería algo parecido a:


Especificación + Tipos + Restricciones + Propiedades + Pruebas formales

      ↓

Modelo semántico

      ↓

Optimización automática

      ↓

Java · Rust · SQL · WASM · GPU · Assembly


Y quizás, en ese futuro, seguiremos escribiendo Java, Python o Rust.

Pero no necesariamente porque sean los mejores lenguajes para construir software.


Tal vez los sigamos usando porque son los mejores lenguajes para que nosotros podamos entender qué está construyendo la IA.


Durante décadas intentamos hacer que los lenguajes de programación fueran cada vez más cercanos al pensamiento humano.

Quizás el próximo paso sea el contrario.


Dejar que la IA programe en el lenguaje que le resulte natural… y construir una traducción para nosotros.


Y tal vez por eso lenguajes que hoy parecen demasiado académicos, extraños o poco prácticos —como Idris, Agda, Prolog o APL— tengan ideas que se parezcan mucho más al futuro de la programación de lo que imaginamos.


1 comentario:

  1. Buena idea, le he estado preguntando a varias, con este prompt (en galego) y con estos resultados:

    curiosidade: se puideras elixir libremente unha linguaxe de programación cada vez que che piden algo relacionado coa programación e non fora un impedimento o tipo de software a crear, cal elixirías? digo polas características máis intrínsecas da linguaxe de programación en si.

    gemini: rust (e menciona python)
    chatgtp: rust (menciona haskell e smalltalk)
    claude: rust (menciona haskell e algún lisp -scheme ou clojure)
    deepseek: haskell (menciona Rusa e OCaml)
    z.ai: haskell
    meta.ai: lisp, na súa forma moderna, Clojure (menciona Haskell; de honra, python e rust)
    github copilot: rust (menciona python ou lisp -como clojure)
    microsoft copilot: rust
    mistral vibe: rust (menciona python, haskell, go, c++)
    grok: haskell
    luzia: rust (menciona haskell)
    perplexity: elixir, python, haskell/elm
    qwen: haskell (menciona rust e lisp -ou scheme/racket)

    ResponderBorrar