A partir de hoy, cada post de este blog se puede escuchar. Abajo a la izquierda aparece un botoncito con un ▶; lo apretás y una voz empieza a leer el artículo, párrafo por párrafo, mientras resalta el que está sonando¹. La voz la pone tu propio navegador.

Antes de escribir la primera ruta de un backend nuevo, vale la pena invertir un rato en el tooling que va a hacer cumplir la calidad del código automáticamente¹. La apuesta es simple: “está prolijo” tiene que ser lo que pasa por default, no lo que alguien se acuerda de hacer antes de un commit. Esto es lo que arma esa base en un proyecto Python real — la configuración es genérica a propósito: no hay una línea de negocio, ni un nombre de cliente, ni nada que identifique de dónde sale. El conjunto de herramientas (tooling) y sus configuraciones iniciales es lo que se puede compartir entre un proyecto y otro. Armé además un scaffold público con todo esto funcionando de verdad — cloná, make install, y andá probando cada sección de este post contra el repo real².

Entre 1982 y 1992, en la misma época en que las vidrieras electrónicas de Tokio ya anunciaban audio, video y calculadoras a los gritos¹, Japón gastó el equivalente a 850 millones de dólares en el Fifth Generation Computer Systems Project (5GCS): una apuesta estatal a redefinir la computación alrededor de la programación lógica concurrente, corriendo sobre hardware paralelo diseñado específicamente para eso. El lenguaje central del proyecto se llamaba KL1 — Kernel Language 1. El proyecto se cerró en 1992 sin haber producido la “máquina que piensa” que prometía. Pero el código sobrevivió. Hace unos años lo recompilé en una laptop moderna y lo hice correr. Esta es la historia de esa reconstrucción.