Brunost Exists: A Programming Language in Nynorsk and What That Says About Who Decides What's Readable

Why do we assume that "natural" code is code written in English? We've spent decades stacking tools on top of tools, everyone perfectly happy with function, class, return — as if those words were neutral. As if they weren't someone's language.

A few days ago, something called Brunost showed up on Hacker News. A programming language written in Nynorsk. Not in English, not in Norwegian Bokmål (the majority written standard), but in Nynorsk — the written form used by roughly 10–15% of Norway, the one many Norwegians themselves consider "weird" within their own country.

The HN score was modest. A few curious comments, a joke or two, and then next page.

It hit me differently.

Alternative programming languages: the topic that looks like a hobby but isn't

I want to be clear about something: this post isn't about Brunost. Brunost is the trigger.

This post is about a question I haven't been able to shake since I saw it: what do we accept as "natural" in the infrastructure of technical language, and why?

I'm Juanchi. Software Architect. I think in Rioplatense Spanish. When I'm furious at a bug, the internal monologue is in Argentine Spanish, with everything that implies. When I truly understand something deep — one of those moments that rewires how you see a system — I process it in Spanish first.

But when I sit down to code, I switch modes. const procesarPedido = (order) => { — there it is, mixed. The verb in Spanish, the noun in English. Not because anyone asked me to. Because that's how I learned it and I never questioned whether there was another way.

That's exactly what Brunost puts on the table.

What exactly is Brunost?

Brunost is an experimental programming language where the keywords are in Nynorsk. funksjon instead of function. returner instead of return. The syntax feels alien if you don't speak the language, but that's precisely the point: every language feels alien to someone.

Nynorsk is an interesting choice because it's not an invented language, not a meme, not Brainfuck for trolls. It's a real, official writing system that the Norwegian state considers equally valid to Bokmål — but one that in practice is constantly marginalized. It's the language of "the mountain people." The one Oslo considers quaint.

The author of Brunost chose exactly that language. I don't think that's accidental.

English as invisible infrastructure

Here's the core of what I want to say.

When we talk about alternative programming languages, we usually think in terms of paradigms: functional vs. imperative, static vs. dynamic typing, manual memory vs. garbage collection. That's the axis where technical conversation happens.

But there's another axis almost nobody touches: the natural language that structures the keywords.

On this axis, English isn't a choice. It's a default so deep it doesn't even appear as an option. It's like standard railway gauge: at some point someone made a decision, and now we build the entire world on top of it without ever asking whether it was the best one.

There are historical exceptions worth mentioning:

• COBOL has something of this — it was designed to "read like English," which already assumes English is the universal language of business
• Logo in Spanish was brought to some Latin American schools in the 80s with keywords in Castilian
• Scratch has translated interfaces, but the base instructions think in English
• Lenguaje Natural (Argentina, 2000s) was an attempt to build a language for non-programmers in Spanish

They're experiments. Curiosities. The mainstream never took them seriously.

Why?

The "interoperability" argument

The most common argument I hear when I bring this up: "if you use keywords in Spanish, you break interoperability with the global ecosystem."

And yeah, technically. But hold on — that argument converts a consequence of the current system into a law of nature. Interoperability doesn't require English per se. It requires a shared standard. English is that standard because it was the language of the universities where all of this was invented in the 50s, 60s, and 70s.

Not because it's more logical. Not because function is clearer than función. Because MIT, Bell Labs, Stanford.

It's history, not destiny.

What happens to me when I name things

Back in 2022 I had that classic tutor moment: a query that took 40 seconds, brought down to 80ms by adding a composite index. Taught me more than any tutorial ever did.

When I explained it to my team, I did it in Spanish. Naturally. With índice_compuesto, consulta_lenta, plan_de_ejecución. And that's when I noticed something: my colleagues understood faster when I used Spanish terms. Not because their technical English was weak, but because conceptual processing goes through the native language first.

Technical mastery has layers. And the deepest layer — the one connected to intuition — operates in the language you think in.

When I later analyzed the real cost of my Claude Code sessions, I noticed that sessions where I thought out loud in Spanish in the prompts produced denser reasoning. I'm not entirely sure why. But I saw it.

The experiment: prompt engineering in Rioplatense Spanish with Claude Code

This is where it gets concrete.

After seeing Brunost, I decided to do something I'd never done systematically: write prompts for Claude Code entirely in Rioplatense Spanish, with zero concessions to technical English.

Not "design a function that processes orders." But:

"I need you to build me a function that takes the pending orders and sorts them by priority, considering that urgent orders have an urgente field set to true and normal ones don't. If there's a tie in urgency, sort by oldest creation date first. Also give me back the total count of urgent orders."

Everything in Spanish. Everything with the vocabulary I use when I'm actually thinking through the problem.

// Types defined with Spanish names
// (because this experiment deserves it)
interface Pedido {
  id: string;
  fechaCreacion: Date;
  urgente: boolean;
  descripcion: string;
}

interface ResultadoOrdenado {
  pedidosOrdenados: Pedido[];
  cantidadUrgentes: number;
}

// The function thinks the way I think about the problem
function ordenarPedidosPorPrioridad(pedidos: Pedido[]): ResultadoOrdenado {
  // Urgent ones first, then normal ones
  // Within each group, oldest first
  const pedidosOrdenados = [...pedidos].sort((a, b) => {
    // If one is urgent and the other isn't, urgent goes first
    if (a.urgente && !b.urgente) return -1;
    if (!a.urgente && b.urgente) return 1;
    
    // If they have the same urgency, oldest goes first
    return a.fechaCreacion.getTime() - b.fechaCreacion.getTime();
  });

  const cantidadUrgentes = pedidos.filter(p => p.urgente).length;

  return { pedidosOrdenados, cantidadUrgentes };
}

The result from Claude Code with the Spanish prompt: the code came out with Spanish comments automatically, without me asking. The intermediate reasoning too. And when it found an edge case (what happens if the list is empty?), it flagged it in Spanish.

Was it "better" than in English? Not in terms of code quality itself. TypeScript is TypeScript. But the process felt different. More fluid. Less mental translation.

That tells me something.

This kind of experiment with AI tools is part of something bigger I'm exploring — how AI agents process context when that context isn't in English, and what gets lost in translation. Also, honestly, how much that extra processing costs when frontier models aren't cheap (something that's shifted quite a bit in the last year).

The gotchas of thinking about this

There are some traps I fell into when I started developing this idea:

Trap 1: romanticizing the alternative Brunost is not better than Python. It's not more expressive. It doesn't solve any problem Python doesn't solve. The value isn't in the technical solution — it's in the question that brings it into existence.

Trap 2: confusing identity with productivity Coding in Spanish doesn't automatically make me more productive. The advantage I noticed in the experiment has more to do with cognitive friction than linguistic pride. Those are different things.

Trap 3: ignoring the real costs If a mixed team (some native Spanish speakers, some not) adopts Spanish variable names, you create an accessibility problem for part of the team. Technical English has a very real privilege: it's the technical second language of almost everyone.

Trap 4: thinking this is a solved problem Seeing projects like curated technical resource lists done entirely in English reminds me that the infrastructure of technical knowledge has language bias baked in. It's not a conspiracy. It's inertia.

FAQ: Alternative programming languages and the language of code

Do other programming languages exist with keywords in non-English languages? Yes, several. Beyond Brunost in Nynorsk, there's Qalb (Arabic), Rapira (Russian, from the Soviet era), and multiple educational projects in Spanish like PseInt for pseudocode. Scratch also allows interfaces in many languages, though the base engine thinks in English. They're marginal experiments, but they exist.

Why did English become the language of code and not something else? Historical context, not technical merit. The universities where modern computing was developed (MIT, Stanford, Bell Labs) operated in English. The first compilers and specs were written in English. Once the ecosystem hit critical mass, the cost of changing exceeded any theoretical benefit of an alternative language. It's path dependency, not intelligent design.

Is there any real technical advantage to naming variables in your native language? There's evidence that conceptual processing happens more naturally in the language you use to think about a problem. For highly specific domains (legal, medical, accounting), using native-language terminology can reduce interpretation errors. For general code, the advantage is marginal but real in educational contexts or monolingual teams.

Do Claude Code and other LLMs handle Rioplatense Spanish prompts well? Better than I expected. Current models understand Rioplatense Spanish with solid fidelity, including idioms. Where they stumble is with very region-specific technical vocabulary or maintaining consistent voice across long outputs. For code, the output tends to be correct but comment style can mix languages if you don't specify explicitly. I'm exploring this as part of how I use these tools.

Is Brunost a "serious" language or a hobby project? It's experimental, which isn't the same as not serious. Experimental projects are where ideas get tested before they go mainstream. A modest HN score says nothing about its conceptual value. The question it asks — what counts as natural language in programming? — is completely serious.

Should I name my variables in my native language? Depends on context. In personal projects or monolingual educational settings, running the experiment is worth it. In mixed teams or open source projects that want international contributions, technical English reduces friction. What I'd always recommend: write your comments in the language your team uses to think through the problem. Comments are reasoning, not interface.

The question I'm left with

Brunost is going to stay a marginal project. Nynorsk is going to keep being the language Norwegians find "quaint." And I'm going to keep writing function and return and class.

But something changed in how I think about the whole thing.

The infrastructure of technical language is not neutral. It has history, it has geography, it has the languages of the people who were in the room when the foundational decisions were made. That doesn't make it illegitimate — it makes it human. And the human stuff can be questioned.

I'm going to keep running the Spanish-prompt experiment. Not because I think it's going to change the world. But because I want to understand where the cognitive friction lives in my own process. And because if Brunost exists — if someone went to the trouble of building a programming language in the minority written standard of Norwegian — the least I can do is ask myself why I never questioned the default.

The code you write says things about you. The language you write that code in does too.

Have you ever tried working completely in your native language in a technical context? What did you notice? I genuinely want to know — especially if your native language isn't English or Spanish.