Translate

Mostrando las entradas con la etiqueta Idris. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Idris. Mostrar todas las entradas

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.


jueves, 27 de agosto de 2026

Quickysort en Idris



Un algoritmo que me gusta mucho es el quicksort, porque es un algoritmo por demás claro. Ya he escrito lo fácil que es implementarlo en Erlang, Rust, haskell y lisp

Ahora le toca a Idris. Básicamente, el algoritmo toma un pivote y agrupa los menores que el pivote al principio y los mayores al final y aplica quicksort a estos dos grupos. Y si la lista es vacía o tiene un elemento, ya está ordenada. 


Vamos al código: 


quicksort : Ord a => List a -> List a

quicksort [] = []

quicksort (pivot :: xs) =

    quicksort (filter (<= pivot) xs)

    ++ [pivot] ++

    quicksort (filter (> pivot) xs)


¿Cómo sabemos que el resultado está realmente ordenado? En Idris podemos intentar expresar esa propiedad en el tipo.

Definimos qué significa “estar ordenado”. Por ejemplo, podemos crear una relación inductiva:


data Sorted : List Nat -> Type where

    Empty : Sorted []

    Single : Sorted [x]

    ...


Y acá empieza lo interesante: Sorted no es un booleano.

No hacemos:

isSorted : List Nat -> Bool


Estamos creando un tipo cuyos valores representan una prueba de que una lista está ordenada.

Conceptualmente:

Sorted [1, 2, 3, 4]

puede tener un valor.


Pero:

Sorted [3, 1, 4]

no debería poder construirse.


Entonces el objetivo final sería algo parecido a:


quicksort :

    (xs : List Nat) ->

    (result : List Nat ** Sorted result)


Es decir: Dame una lista y te devuelvo una lista junto con una prueba de que esa lista está ordenada.

QuickSort es bastante fácil de escribir. Demostrarlo no.


Porque cuando hacemos:

menores ++ [pivot] ++ mayores


no alcanza con demostrar que:

menores está ordenado;

mayores está ordenado.


También necesitamos demostrar que:

todos los elementos de menores <= pivot

y:

pivot < todos los elementos de mayores


Es decir, Idris nos obliga a hacer explícito algo que normalmente dejamos implícito en nuestra cabeza.


Y entonces?

Primero definimos qué significa que una lista esté ordenada:

data Sorted : List Nat -> Type where

  Empty  : Sorted []

  Single : Sorted [x]

  Cons   : LTE x y ->

           Sorted (y :: xs) ->

           Sorted (x :: y :: xs)


La parte interesante viene con la firma de quicksort:

quicksort :

  (xs : List Nat) ->

  (result : List Nat ** Sorted result)


Veamos el código completo: 

quicksort :

    (xs : List Nat) ->

    (result : List Nat ** Sorted result)


quicksort [] =

    ([] ** Empty)


quicksort (pivot :: xs) =

    let (left ** leftSorted) =

            quicksort (filter (<= pivot) xs)

        (right ** rightSorted) =

            quicksort (filter (> pivot) xs)


        result =

            left ++ [pivot] ++ right

    in

        (result ** ?proof)



lunes, 20 de junio de 2016

Porque Haskell no implementa dependently typed?

Seguramente se lo han preguntado, si esta tan bueno dependently typed, porque no lo implementa Haskell?

El problema es que debería romper la restricción de fase entre el tipo y niveles de valor que permite Haskell para ser compilado a código máquina eficiente. Con nuestro nivel actual de la tecnología, un lenguaje dependently typed debe correr sobre una maquina virtual o interprete.

Idris es compila a C pero tiene un garage collector, la verdad no se bien como lo hace. Alguien me ayuda?


domingo, 27 de marzo de 2016

Dependently typed languages

Existe una lucha en la oscuridad que nosotros poco conocemos entre tipado dinámico y estático. En cualquier sitio de programación se ven tablas comparativas con ventajas y desventajas de cada uno.

En el plano de la investigación hubo un gran adelanto en este tema con las teorías de dependently typed languages, que expanden los limites del tipado estático.

Dependent type es un concepto de la programación pero también de la lógica; Dependent type es un tipo que depende de un valor. En la programación funcional se utiliza para prevenir errores, al permitir un sistema de tipo extensivo.

Dependent type añaden complejidad a un sistema de tipos. Es decir, para saber un tipo en algunos casos se deben realizar cálculos o ejecutar sentencias; esto hace bastante complejo el proceso de chequeo de tipos; y en algunos casos imposible. Pero algunos aspectos del comportamiento de un programa se pueden especificar con precisión en el tipo.

Entre los lenguajes que implementan esta tecnica tenemos:

Agda: Agda es un lenguaje funcional con dependent typed. Es similar a Epigram pero con una sintaxis más parecida a Haskell-like syntax.

Idris: Lenguaje de proposito general muy parecido a haskell pero con  dependent typed

Cayenne: Este lenguaje fue influido por la teoría constructive type (pero eso es para otro post)

Que ventajas trae Dependently typed:
-Se pueden encontrar más errores en tiempo de compilación
-Editores que nos ayuden más
-Puede checkear que los elementos de tu programa estén bien.

Todo muy lindo, pero vamos con algo menos abstracto, vamos a ver una definición de tipo en Idris:

data Vect : Nat -> Type -> Type where
    Nil : Vect Z a
    (::) : a -> Vect k a -> Vect (S k) a

ufff, y yo pienso que mi vida es complicada...

Veamos, en la primera linea decimos, que definimos una familia de tipos que toman un Nat y retornan un tipo. Entonces le decimos cuando, en esta sentencia tiene que haber siempre al menos un verdadero. Es parecido a pattern maching pero con tipos.

Este tema es muy interesante voy a seguir con esto en futuros post.

Dejo link: https://wiki.haskell.org/Dependent_type

jueves, 9 de julio de 2015

Seven More Languages in Seven Weeks: Languages That Are Shaping the Future

Alguna vez les hable del libro 7 lenguajes en 7 semanas, bueno las editorial The Pragmatic Bookshelf ha lanzado un nuevo libro con la misma temática. Los lenguajes a analizar son  Lua, Factor, Elm, Elixir, Julia, MiniKanren y Idris.

Y hasta tiene video y todo: 




Ya saben que regalarme!!

Dejo el link:
https://pragprog.com/book/7lang/seven-more-languages-in-seven-weeks


domingo, 15 de diciembre de 2013

Idris, un lenguaje de programación con Dependent type


Idris es un lenguaje funcional de propósito general, con una particularidad es un lenguaje con Dependent type. Ahora viene la pregunta ¿que es Dependent type? Dependent type es un concepto de la programación pero también de la lógica; Dependent type es un tipo que depende de un valor. En la programación funcional se utiliza para prevenir errores, al permitir un sistema de tipo extensivo.

Dependent type añaden complejidad a un sistema de tipos. Es decir, para saber un tipo en algunos casos se deben realizar cálculos o ejecutar sentencias; esto hace bastante complejo el proceso de chequeo de tipos; y en algunos casos imposible. Pero algunos aspectos del comportamiento de un programa se pueden especificar con precisión en el tipo.

Idris es un lenguaje muy similar a haskell; pero con la propiedad de Dependent type.

Dejo links:
http://www.idris-lang.org/