Los proyectos "inútiles" nunca son completamente inútiles

No todos los proyectos personales necesitan usuarios, ingresos o una ruta clara hacia producción.

A veces su única justificación es una pregunta que no te deja en paz: ¿cómo funciona esto por dentro?

Hace algún tiempo esa pregunta me llevó a tomar un curso sobre construcción de compiladores. No porque necesitara crear uno para el trabajo, ni porque tuviera un producto esperando ser lanzado. Simplemente me parecía fascinante que un archivo de texto pudiera convertirse en algo que una máquina entendiera y ejecutara.

En el camino aparecieron palabras que, hasta entonces, eran más bien parte del vocabulario de otros desarrolladores: lexer, tokens, gramáticas, parser, AST. Poco a poco dejaron de ser términos abstractos. Empecé a entender que un compilador no “lee código” como lo hacemos nosotros; lo transforma en representaciones cada vez más explícitas hasta que cada pieza tiene un lugar y un significado.

De esa curiosidad nació Codexivo, un lenguaje de programación básico pensado para personas cuya lengua materna es el español. La idea era sencilla: antes de enfrentar la sintaxis y las convenciones de un lenguaje de producción, una persona podía concentrarse en la lógica. Variables, condiciones, ciclos, funciones y estructuras elementales, pero expresadas con palabras cercanas.

No era un proyecto con una aplicación profesional inmediata. Era una manera de aprender construyendo.

La historia original quedó documentada en La creación de mi propio lenguaje de programación, seguida por la entrada sobre sus tokens. Y sí: esa primera serie quedó incompleta justo cuando llegaba el parser. Años después, esa pausa terminó siendo el prólogo de esta otra historia.

El código de aquel experimento sigue disponible en el repositorio de Codexivo.

El valor que no se puede medir al terminar

Mientras trabajaba en Codexivo, el objetivo visible era el lenguaje: definir palabras clave, reconocer símbolos, construir expresiones y darles significado. Sin embargo, lo que realmente quedó fue otra cosa: una forma de mirar el texto.

Un programa deja de ser un bloque de caracteres cuando aprendes a verlo como una estructura.

Código fuente
    ↓
tokens
    ↓
parser
    ↓
árbol sintáctico
    ↓
modelo que puede recorrerse y transformarse

Ese modelo mental no se nota mucho cuando el proyecto está en pausa. De hecho, desde fuera, Codexivo podía parecer uno de esos proyectos que nunca “sirven” para nada. No tenía usuarios, no resolvía un dolor urgente y tampoco se convirtió en una empresa.

Pero los proyectos de curiosidad no siempre entregan valor en la misma forma en que lo hace un producto. A veces entregan intuición. Y la intuición se queda contigo.

Años después, un problema que no parecía relacionado

Tiempo después apareció una necesidad completamente distinta: procesar documentos legislativos.

El punto de partida era un archivo Markdown con el contenido de una ley. El objetivo no era mostrarlo bonito en una página; era poder trabajar sobre él. Consultarlo, encontrar partes específicas, identificar cambios y, eventualmente, consolidar reformas.

La necesidad se veía más o menos así:

Texto plano
    ↓
estructura procesable
    ↓
operaciones sobre la ley

La conexión llegó casi de inmediato: esto se parece sospechosamente a construir un compilador.

No porque una ley sea código ejecutable, sino porque tampoco es texto libre. Tiene una gramática propia. Sus elementos se repiten, siguen convenciones y ocupan una posición dentro de una jerarquía:

Ley
└── Título Primero
    └── Capítulo I
        └── Sección Primera
            └── Artículo 1
                ├── Párrafo
                ├── Fracción I
                └── Fracción II
                    └── Inciso a)

Un programa tiene keywords, identificadores, expresiones, bloques y scopes. Una ley tiene títulos, capítulos, secciones, artículos, párrafos, fracciones, incisos, referencias y numeraciones. Ambos documentos necesitan contexto para que sus partes tengan sentido.

En ese momento dejó de ser “un Markdown largo”. Era un lenguaje estructurado que había que interpretar.

Del AST al ALT

La primera consecuencia fue natural: si podía identificar las estructuras de una ley, podía convertirlas en tokens legislativos.

Artículo 254.
    ↓
ARTICLE(254)

TÍTULO PRIMERO
DISPOSICIONES GENERALES
    ↓
TITLE(PRIMERO, "DISPOSICIONES GENERALES")

Después, un parser podía decidir dónde colocar cada token según el tipo de elemento, el nivel jerárquico, la indentación y el contexto previo. Así nació el ALT: Abstract Law Tree.

Markdown legislativo
    ↓
Lexer
    ↓
Tokens legislativos
    ↓
Parser
    ↓
ALT

El ALT no pretende reemplazar el texto original. Representa la estructura lógica que el parser entendió. En otras palabras: no es la ley como está escrita en una página; es la ley como un sistema puede recorrerla, consultar sus nodos y razonar sobre sus relaciones.

La conexión inesperada

El conocimiento para empezar ese parser no vino del mundo legal. Vino de un curso tomado por curiosidad y de un lenguaje educativo que no tenía una urgencia comercial.

Codexivo no tuvo que convertirse en un producto exitoso para ser útil. Me dejó un modelo mental: cuando un problema parece ser texto, vale la pena preguntarse si en realidad es un lenguaje con estructura.

Esa es, para mí, la utilidad real de muchos proyectos “inútiles”. No siempre producen algo que vas a usar mañana. A veces producen una manera nueva de reconocer problemas.

Y años después, frente a un documento de cientos de páginas, tu cerebro dice:

Espera. Yo ya vi algo parecido.

Crear el ALT resolvió cómo entender una ley. Pero muy pronto apareció una pregunta mucho más difícil: entender una ley no es lo mismo que poder versionarla.