¿Por qué asumimos que el código "natural" es el que está en inglés? Llevamos décadas construyendo herramientas sobre herramientas, todos felices con function, class, return, como si esas palabras fueran neutrales. Como si no fueran el idioma de alguien.
Hace unos días apareció en Hacker News un proyecto llamado Brunost. Un lenguaje de programación escrito en Nynorsk. No en inglés, no en noruego bokmål (la variante mayoritaria), sino en Nynorsk —la forma escrita que usa aproximadamente el 10-15% de Noruega y que muchos noruegos consideran "rara" dentro de su propio país.
El score en HN fue modesto. Un par de comentarios curiosos, algún chiste, y a la siguiente página.
A mí me golpeó diferente.
Lenguajes de programación alternativos: el tema que parece hobby pero no lo es
Quiero ser claro sobre algo: este post no es sobre Brunost. Brunost es el detonante.
Este post es sobre una pregunta que me estoy haciendo desde que lo vi y que no puedo soltar: ¿qué aceptamos como "natural" en la infraestructura del lenguaje técnico, y por qué?
Yo soy Juanchi. Arquitecto de Software. Pienso en rioplatense. Cuando me enojo con un bug, el monólogo interno es en castellano porteño, con todo lo que eso implica. Cuando entiendo algo profundo —de esos momentos que te cambian cómo ves un sistema— lo proceso en castellano primero.
Pero cuando me siento a programar, cambio de modo. const procesarPedido = (order) => { —ahí está, mezclado. El verbo en castellano, el sustantivo en inglés. No porque alguien me lo pidió. Porque lo aprendí así y nunca cuestioné si había otra forma.
Eso es exactamente lo que Brunost pone sobre la mesa.
¿Qué es Brunost exactamente?
Brunost es un lenguaje de programación experimental donde las palabras clave están en Nynorsk. funksjon en vez de function. returner en vez de return. La sintaxis te resulta alienante si no hablás el idioma, pero eso es precisamente el punto: todo lenguaje le resulta alienante a alguien.
Nynorsk es interesante como elección porque no es una lengua inventada, no es un meme, no es Brainfuck para trollear. Es un sistema de escritura real, oficial, que el estado noruego considera igual de válido que bokmål —pero que en la práctica cultural está constantemente marginado. Es el idioma de "los de las montañas". El que la gente de Oslo considera pintoresco.
El autor de Brunost eligió exactamente ese idioma. Eso no me parece accidental.
El inglés como infraestructura invisible
Acá viene el nudo de lo que quiero decir.
Cuando hablamos de lenguajes de programación alternativos, generalmente pensamos en paradigmas: funcional vs imperativo, tipado estático vs dinámico, memoria manual vs garbage collector. Ese es el eje donde pasa la conversación técnica.
Pero hay otro eje que casi nadie toca: el idioma natural que estructura las palabras clave.
En este eje, el inglés no es una elección. Es el default tan profundo que ni aparece como opción. Es como el ancho de vía estándar en ferrocarriles: en algún momento alguien tomó una decisión, y ahora construimos todo el mundo sobre ella sin preguntarnos si fue la mejor.
Hay excepciones históricas que vale mencionar:
- COBOL tiene algo de esto —fue diseñado para ser "leído como inglés", lo cual ya asume que el inglés es el lenguaje universal del negocio
- Logo en español fue llevado a algunas escuelas latinoamericanas en los 80s con palabras clave en castellano
- Scratch tiene interfaces traducidas, pero las instrucciones base piensan en inglés
- Lenguaje Natural (Argentina, 2000s) fue un intento de crear un lenguaje para no programadores en castellano
Son experimentos. Curiosidades. El mainstream nunca los tomó en serio.
¿Por qué?
El argumento de "la interoperabilidad"
El argumento más común que escucho cuando planteo esto: "si usás palabras clave en español, rompés la interoperabilidad con el ecosistema global".
Y sí, técnicamente. Pero esperen —ese argumento convierte una consecuencia del sistema actual en una ley natural. La interoperabilidad no requiere inglés per se. Requiere un estándar compartido. El inglés es ese estándar porque fue el idioma de las universidades donde se inventó todo esto en los 50s-60s-70s.
No porque sea más lógico. No porque function sea más claro que función. Porque MIT, Bell Labs, Stanford.
Es historia, no destino.
Lo que me pasa a mí cuando nombro las cosas
En 2022 tuve ese momento clásico de tutor: una query que tardaba 40 segundos la bajé a 80ms agregando un índice compuesto. Lo que me enseñó más que cualquier tutorial.
Cuando lo expliqué a mi equipo, lo hice en castellano. Naturalmente. Con índice_compuesto, consulta_lenta, plan_de_ejecución. Y ahí fue donde noté algo: mis colegas entendieron más rápido cuando usé términos en español. No porque fueran peores en inglés técnico, sino porque el procesamiento conceptual pasa por el idioma nativo primero.
El dominio técnico tiene capas. Y la capa más profunda, la que conecta con la intuición, opera en el idioma en que pensás.
Cuando después analicé el costo real de mis sesiones con Claude Code, noté que las sesiones donde pensaba en voz alta en castellano en los prompts producían razonamientos más densos. No estoy seguro de por qué. Pero lo vi.
El experimento: prompt engineering en rioplatense con Claude Code
Acá es donde se pone concreto.
Después de ver Brunost, decidí hacer algo que nunca había hecho de forma sistemática: escribir prompts para Claude Code completamente en castellano rioplatense, sin concesiones al inglés técnico.
No "diseñar una función que procese orders". Sino:
"Necesito que me armés una función que tome los pedidos pendientes y los ordene por prioridad, considerando que los pedidos urgentes tienen un campo urgente en true y los normales no. Si hay empate en urgencia, ordená por fecha de creación más vieja primero. Devolveme también cuántos pedidos urgentes hay en total."
Todo en castellano. Todo con el vocabulario que uso cuando pienso el problema.
// Tipos definidos con nombres en español
// (porque este experimento lo merece)
interface Pedido {
id: string;
fechaCreacion: Date;
urgente: boolean;
descripcion: string;
}
interface ResultadoOrdenado {
pedidosOrdenados: Pedido[];
cantidadUrgentes: number;
}
// La función piensa como yo pienso el problema
function ordenarPedidosPorPrioridad(pedidos: Pedido[]): ResultadoOrdenado {
// Primero los urgentes, después los normales
// Dentro de cada grupo, el más viejo primero
const pedidosOrdenados = [...pedidos].sort((a, b) => {
// Si uno es urgente y el otro no, el urgente va primero
if (a.urgente && !b.urgente) return -1;
if (!a.urgente && b.urgente) return 1;
// Si tienen la misma urgencia, el más viejo va primero
return a.fechaCreacion.getTime() - b.fechaCreacion.getTime();
});
const cantidadUrgentes = pedidos.filter(p => p.urgente).length;
return { pedidosOrdenados, cantidadUrgentes };
}
El resultado de Claude Code con el prompt en castellano: el código salió con comentarios en español automáticamente, sin que yo lo pidiera. El razonamiento intermedio también. Y cuando encontró un edge case (¿qué pasa si la lista está vacía?), me lo señaló en castellano.
¿Fue "mejor" que en inglés? No en términos de calidad del código en sí. El TypeScript es TypeScript. Pero el proceso se sintió diferente. Más fluido. Menos traducción mental.
Eso me dice algo.
Este tipo de experimentos con herramientas de IA son parte de algo más grande que estoy explorando —cómo los agentes de IA procesan contexto cuando ese contexto no es en inglés, y qué se pierde en la traducción. También, honestamente, cuánto cuesta ese procesamiento extra cuando los modelos frontier no son baratos (algo que cambió bastante en el último año).
Los gotchas de pensar en esto
Hay algunas trampas en las que caí cuando empecé a desarrollar este tema:
Trampa 1: romanticizar lo alternativo
Brunost no es mejor que Python. No es más expresivo. No resuelve ningún problema que Python no resuelva. El valor no está en la solución técnica sino en la pregunta que hace existir.
Trampa 2: confundir identidad con productividad
Programar en castellano no me hace más productivo automáticamente. La ventaja que noté en el experimento tiene más que ver con fricción cognitiva que con orgullo lingüístico. Son cosas distintas.
Trampa 3: ignorar los costos reales
Si un equipo mixto (algunos nativos en español, algunos no) adopta nombres de variables en castellano, creás un problema de accesibilidad para parte del equipo. El inglés técnico tiene un privilegio bastante real: es el segundo idioma técnico de casi todo el mundo.
Trampa 4: creer que esto es un problema resuelto
Ver proyectos como listas curadas de recursos técnicos completamente en inglés me recuerda que la infraestructura del conocimiento técnico tiene sesgo de idioma baked in. No es conspiración. Es inercia.
FAQ: Lenguajes de programación alternativos y el idioma del código
¿Existen otros lenguajes de programación con palabras clave en idiomas no ingleses?
Sí, varios. Además de Brunost en Nynorsk, existe Qalb (árabe), Rapira (ruso, de la era soviética), y múltiples proyectos educativos en español como PseInt para pseudocódigo. También Scratch permite interfaces en muchos idiomas, aunque el engine base piensa en inglés. Son experimentos marginales, pero existen.
¿Por qué el inglés se convirtió en el idioma del código y no otro?
Por contexto histórico, no por mérito técnico. Las universidades donde se desarrolló la computación moderna (MIT, Stanford, Bell Labs) operaban en inglés. Los primeros compiladores y especificaciones se escribieron en inglés. Una vez que el ecosistema tuvo masa crítica, el costo de cambiar superó cualquier beneficio teórico de un idioma alternativo. Es path dependency, no diseño inteligente.
¿Hay alguna ventaja técnica real en nombrar variables en el idioma nativo?
Hay evidencia de que el procesamiento conceptual ocurre más naturalmente en el idioma en que uno piensa un problema. Para dominios muy específicos (legales, médicos, contables), usar terminología en el idioma nativo puede reducir errores de interpretación. Para código general, la ventaja es marginal pero real en contextos educativos o equipos monolingües.
¿Claude Code y otros LLMs manejan bien los prompts en español rioplatense?
Mejor de lo que esperaba. Los modelos actuales entienden castellano rioplatense con buena fidelidad, incluyendo modismos. Donde fallan es en vocabulario técnico regional muy específico o en mantener la voz de forma consistente en outputs largos. Para código, el output tiende a ser correcto pero el estilo de comentarios puede mezclar idiomas si no se especifica explícitamente. Lo estoy explorando como parte de cómo uso estas herramientas.
¿Es Brunost un lenguaje "serio" o es un proyecto de hobby?
Es experimental, lo cual no es lo mismo que no serio. Los proyectos experimentales son donde se prueban las ideas antes de que sean mainstream. Que tenga un score modesto en HN no dice nada sobre su valor conceptual. La pregunta que hace —¿qué cuenta como lenguaje natural en programación?— es completamente seria.
¿Debería nombrar mis variables en castellano?
Depende del contexto. En proyectos personales o educativos monolingües, hacer el experimento vale la pena. En equipos mixtos o proyectos open source que quieran contribuciones internacionales, el inglés técnico reduce fricción. Lo que sí recomendaría siempre: escribir los comentarios en el idioma en que el equipo piensa el problema. Los comentarios son razonamiento, no interfaz.
La pregunta que me queda
Brunost va a seguir siendo un proyecto marginal. Nynorsk va a seguir siendo el idioma que los noruegos encuentran "pintoresco". Y yo voy a seguir escribiendo function y return y class.
Pero algo cambió en cómo pienso el tema.
La infraestructura del lenguaje técnico no es neutral. Tiene historia, tiene geografía, tiene los idiomas de las personas que estaban en la sala cuando se tomaron las decisiones fundacionales. Eso no la hace ilegítima —la hace humana. Y lo humano se puede cuestionar.
El experimento del prompt en castellano lo voy a seguir. No porque crea que va a cambiar el mundo. Sino porque me interesa entender dónde está la fricción cognitiva en mi propio proceso. Y porque si Brunost existe —si alguien se tomó el trabajo de construir un lenguaje de programación en la variante minoritaria del noruego— lo mínimo que puedo hacer es preguntarme por qué yo nunca cuestioné el default.
El código que escribís dice cosas sobre vos. El idioma en que escribís ese código también.
¿Hiciste alguna vez el experimento de trabajar completamente en tu idioma nativo en un contexto técnico? ¿Qué notaste? Me interesa saber —especialmente si tu idioma nativo no es inglés ni español.
Este artículo fue publicado originalmente en juanchi.dev
