(¿no tienes paciencia? ver ya)
Punk: anatomía de un lenguaje →

De todo lo que hay en este sitio, Punk es la madriguera más profunda. Es un lenguaje de programación que compila a ejecutables nativos: yo escribo Punk, el compilador hace su trabajo por debajo y sale un binario rápido, sin máquina virtual ni intérprete de por medio.

Lo que de verdad me quita el sueño: la memoria

La pregunta que ha consumido la mayor parte del proyecto no es cómo imprimo algo, sino quién es el dueño de cada valor y quién lo libera. Punk no tiene recolector de basura, pero tampoco te obliga a escribir free a mano: lo decide el compilador, en tiempo de compilación.

El modelo es de ownership implícito, al estilo del String de Rust:

• Préstamo por defecto. Cuando lees un valor (x := rec.campo), tomas una vista, no una copia. El original sigue vivo y usable.
• Move al escapar. Si un valor se escapa de su función (lo retornas, lo guardas en algo que sobrevive) y su origen ya no se usa, la propiedad se traslada limpiamente.
• .clone() explícito. La única forma de obtener una copia profunda independiente. El lenguaje nunca aloca a tus espaldas: la duplicación se ve en el código.

Debajo hay un análisis de escape que decide qué vive en la pila y qué en el montón, y un bump allocator como respaldo para los temporales. Todo se resuelve antes de ejecutar nada, sin metadatos ni comprobaciones en runtime.

Los conceptos que quise llevarme conmigo

• Un sistema de tipos donde cada primitivo mapea 1:1 al tipo nativo que le corresponde — sin magia, lo que ves es lo que se ejecuta.
• Una taxonomía de subprogramas donde la forma de declararlos es su contrato: una fn es pura y el checker rechaza cualquier efecto; un bare proc puede hacer IO; un método con receptor muta su record.
• Colecciones clásicas con su implementación real y nombrada — Seq, Stack, Queue, Heap, HashMap, TreeMap, varios tipos de set… porque la implementación es parte de la lección.
• Contratos integrados en la firma (pre/post/law/rescue).
• Una «cara densa» para sintetizar mucho en poco: lambdas con captura, orden superior, operadores Unicode (∩ ∪ ∈ ¬ ∧), pipe |>, comprensiones e interpolación de strings.

Voy por la versión 0.94, que es mi forma elegante de decir «todavía no he terminado, y puede que nunca». Y precisamente por eso me gusta.

¿Y corre rápido?

Toda esta obsesión con la memoria tiene un objetivo medible. Resolver la propiedad en tiempo de compilación, sin recolector ni comprobaciones en runtime, debería notarse en el reloj. Así que lo medí: las mismas tareas escritas en Punk y en Python 3, cronometradas una al lado de la otra.

El binario nativo de Punk gana en casi todo, y por márgenes amplios en lo numérico (numeric: 0.01s frente a 0.92s) y en el encode (0.32s frente a 8.45s). Las dos tareas marcadas con * —fasta y translate— corren sobre un archivo de 2 millones de líneas: ahí el cuello de botella es el disco, no el lenguaje, así que esos tiempos dicen más del I/O que de Punk. En el resto, donde de verdad se compara código contra código, la ventaja es consistente.

No es una promesa de que Punk sea «más rápido que Python» en abstracto —es mi lenguaje personal, no un competidor—, pero confirma que el modelo de memoria no es solo elegante sobre el papel: se paga en velocidad.

Para verlo entero

La anatomía completa —sintaxis, tipos, el modelo de memoria, las colecciones y el vocabulario, con buscadores— está en el lab:

Punk: anatomía de un lenguaje →