Por qué creé Ori — y cómo la estoy creando

Capítulos

De dónde vengo

Mi formación es en Marketing y Diseño. Pasé por preimpresión, endomarketing y soporte de TI, y el código que escribía se resumía a CRUDs en PHP y Ruby. Nada que sugiriera “un día este tipo va a diseñar un lenguaje de programación”.

Lo que tenía — y sigo teniendo — es una curiosidad que no se apaga. Me gusta entender cómo funcionan las cosas por dentro, y tengo ese hiperfoco clásico de quien aprende cosas totalmente fuera de su área solo porque algo le intrigó. Cuando empecé a construir software junto a la IA, el techo de “solo sé lo básico” se rajó: de repente podía llevar ideas mucho más grandes hasta el final, siempre que supiera hacer las preguntas correctas y juzgar las respuestas.

Ori nació de ese lugar. No de un laboratorio de lenguajes, sino de alguien que leía mucho más código del que escribía — y eso le molestaba.

Antes de Ori: Zenith, C y Auk9

Ori no fue el primer intento — fue el tercero que sobrevivió. Cuando empecé, el lenguaje se llamaba Zenith Language, y la primera versión fue escrita en C. En ese momento tenía sentido: los lenguajes de sistemas se escriben en C, ¿no? Mal para mi caso. Pasé más tiempo cazando bugs de memoria — punteros colgantes, frees dobles, corrupción silenciosa — que diseñando el lenguaje en sí. Las particularidades de memoria de C cobraban un precio que yo no podía pagar: cada idea nueva venía acompañada de una semana de debugging que no enseñaba nada sobre lenguajes, solo sobre supervivencia en C.

Después vino Auk9, ya en Rust — y esa también fue descartada como producto. Pero descartar no fue perder: varios conceptos de Auk9 sobrevivieron y viven hoy en Ori. Ahí entendí algo importante: tirar una versión puede ser progreso, siempre que los conceptos aprendidos viajen con uno.

El punto más honesto: empecé sin entender casi nada de cómo funciona un lenguaje por dentro — de manera explícita, quiero decir. Yo usaba lenguajes, no entendía lenguajes. Fue haciendo preguntas, una tras otra, que apareció el camino: leer sobre compiladores, gestión y arquitectura de memoria, runtime, lexer, parser. Cada pregunta tiraba de otra. Hasta hoy puede que no sepa el 100% de cada línea del código desarrollado, pero entiendo gran parte del mecanismo — lo suficiente para seguir conversaciones sobre cómo funcionan los lenguajes e incluso “arañar un poco” en ellas. Para alguien que venía de CRUD en PHP, eso ya es todo un viaje.

Por qué crear un lenguaje

La pregunta que me persigue desde hace años es simple: ¿por qué casi todo lenguaje optimiza para quien escribe, si pasamos mucho más tiempo leyendo? Cada atajo sintáctico parece inofensivo solo. Pero suma cientos de ellos en un proyecto real y leer se convierte en decodificar. Para quien llega, para quien tiene TDAH y necesita estructura explícita, para un code agent que debe entender un módulo sin cargar todo el repositorio — la cuenta llega.

Al principio pensaba que era solo cuestión de estilo. Cuanto más miraba, más me parecía un problema de arquitectura del propio lenguaje: la legibilidad no es cosmética, es la interfaz más usada del sistema. Y casi nadie diseña un lenguaje empezando por ella.

También quería responder una segunda pregunta: ¿hasta dónde puede llevar una persona fuera del área — con la IA como compañera — el diseño de un lenguaje serio? Ori es, además de todo, ese experimento.

Lo que Ori es — y lo que no es

Ori es un lenguaje reading-first, de tipos explícitos, compilado a código nativo (AOT), con su compilador escrito en Rust. Leer un programa Ori debería parecerse a leer una especificación: nombres que dicen lo que hacen, poca magia, flujo visible.

Lo que no es: no es un intento de reemplazar a Rust, Go ni a ningún lenguaje establecido. No es un producto para competir en el mercado. Existe para el estudio de compiladores, para la programación asistida por IA y para la legibilidad — incluso para cerebros que funcionan como el mío. Esa honestidad sobre el alcance me libera para tomar decisiones impopulares cuando sirven a la lectura.

Y está el motivo que está por encima de todos los técnicos: no quiero crear un producto, ni nada para el mercado. Quiero hacer algo que me haga feliz — crear mis experimentos, jugar con las herramientas y, a lo largo de todo este viaje, aprender y divertirme. Si Ori termina siendo útil para más gente, genial. Pero el objetivo principal ya se está cumpliendo cada vez que me divierto diseñándola.

Cómo la creé: las decisiones

Nada aquí nació listo. El proceso fue más o menos así: idea inicial, primera posibilidad, consecuencia inesperada, comparación con alternativas, refinamiento. Algunas decisiones importantes y sus trade-offs:

Compilador en Rust, objetivo nativo (AOT). El camino obvio sería algo interpretado primero — más rápido de prototipar. Pero AOT me obliga a llevar cada feature hasta el codegen, lo que funciona como prueba de sanidad del diseño: si una idea no sobrevive a la compilación nativa, quizá no era tan buena. El costo es velocidad de iteración, y lo pago con los ojos abiertos. Para experimentos rápidos existe el modo ori run, con JIT opcional.

Tipos explícitos, sin adivinanzas. La inferencia agresiva ahorra escritura y cobra lectura: nunca sabes con certeza qué tipo fluye ahí sin preguntar a la herramienta. Como la propuesta es reading-first, ganó lo explícito. Es más verboso, por tanto — y prefiero verbosidad honesta a concisión misteriosa.

Sintaxis legible por defecto. Cualquier azúcar sintáctico debe justificar su existencia probando que no perjudica la lectura. Esa regla ya mató varias ideas que amé el primer día y odié en la primera relectura. Releer, por cierto, se volvió método: si no entiendo mi propio código una semana después sin esfuerzo, la sintaxis falló.

Tooling desde el día uno. LSP, diagnósticos claros, ejemplos ejecutables. La documentación y los errores amables dan tanto trabajo como el compilador — y en un lenguaje reading-first, un error críptico traiciona toda la propuesta. Así que un buen error no es polish, es requisito.

Especificación abierta. Todo — manifiesto, spec, planificación, changelog — vive en el repositorio. Eso no es solo transparencia: es lo que permite que agentes (y personas) trabajen en el proyecto con contexto real, en vez de adivinar intenciones.

Construyendo junto a la IA

Necesito ser honesto en un punto: no habría llegado hasta aquí solo, y no finjo lo contrario. La IA escribe borradores, explora alternativas, señala agujeros en mi razonamiento. Mi trabajo es otro: decidir. Juzgar trade-offs, mantener la visión coherente, decir no a buenas ideas que no sirven a este proyecto.

Funciona porque trato a la IA como compañera de investigación, no como oráculo. Pregunto “¿cuáles son las alternativas?”, “¿qué se rompe si lo hago así?”, “muéstrame dónde ya se intentó esto”. Y desconfío de respuestas muy seguras — incluidas las mías.

Hay un efecto colateral interesante: diseñar un lenguaje asistido por IA me enseñó mucho sobre lo que hace legible el código para las IAs. Fronteras explícitas, decisiones documentadas, ejemplos pequeños y completos. En el fondo, lo que ayuda a un agente a entender el código ayuda también a una persona — sobre todo a una persona con memoria de trabajo limitada, como yo.

Estado actual y próximos pasos

Ori está pre-1.0: la superficie actual es S3, la sintaxis anterior se rechaza, y aún se permiten cambios antes de un contrato estable. Pondría el proyecto en 7/10 hoy — la base (parser, tipos, codegen, spec) existe y compila programas reales, pero aún faltan mejores diagnósticos, más ejemplos, profiling y validación con gente real usándolo.

El próximo paso que puede confirmar o tumbar las decisiones es siempre el mismo: compilar ejemplos no triviales, medir y observar dónde duele. Si el dolor se repite en el mismo lugar, ahí vive la próxima decisión.

Todo abierto en el repositorio: manifiesto, especificación, ejemplos y changelog. Si tú también lees más de lo que escribes, quizá este lenguaje sea para ti.