---
title: "We Should Be Able to Change Our Languages"
slug: we-should-be-able-to-change-our-languages
url: https://listedarticles.com/articles/we-should-be-able-to-change-our-languages
canonical_url: http://jimmyhmiller.com/change-our-languages
content_type: essay
language: en
published_at: 2026-09-01T12:00:00.000Z
updated_at: 2026-09-27T09:12:57.878Z
author: "Jimmy Miller"
author_url: http://jimmyhmiller.com
authored_by: human
publisher: "Jimmy Miller"
publisher_url: http://jimmyhmiller.com
topics: ["Programming", "TypeScript", "LLMs", "Developer Tools", "Opinion"]
license: all-rights-reserved
word_count: 535
reading_minutes: 2
citation: "Jimmy Miller, Jimmy Miller. \"We Should Be Able to Change Our Languages.\" 1 Sept 2026. http://jimmyhmiller.com/change-our-languages (all-rights-reserved)"
# The full text follows. The web page shows an extract and sends readers
# to the source above; quote the citation and link the canonical URL.
---

# We Should Be Able to Change Our Languages

> Jimmy Miller argues AI-era coding makes language macros newly practical, introduces Sweetener for TypeScript, and asks why we still fear customizable programming languages.

# We Should Be Able to Change Our Languages

**Author:** Jimmy Miller  
**Published:** September 2026  
**Source:** [jimmyhmiller.com](http://jimmyhmiller.com/change-our-languages)

Programming languages are fixed artifacts. Defined by committee or that one really smart person. They are sacred artifacts whose contours are fixed for good reasons. The idea of changing your programming language, of customizing it for your own needs, is a drastic measure that should never be done. Or at least that's how people act. In a world where software is becoming increasingly flexible, moldable, editable, our programming languages resist this change.

Instead, we build incredibly complicated build systems. We create complex conventions that give us the semantics we wished our languages had. We reuse existing language constructs and give them different meanings. We form committees to advocate for changes to our languages, bike-shedding endlessly, because the idea of just letting each individual codebase make its own decisions offends our sensibilities.

## Why We Resist

The ability for people to define their language to be the way they want is not new. It isn't difficult. But there has been a large backlash against it for decades. People avoid languages that offer this functionality. Even in languages that have it, some teams choose to completely ban it.

Raymond Chen's 2005 blog post *A rant against flow control macros* puts the common argument well: when you create a flow-control macro, you're modifying the language — and people expect `.cpp` files to be C++, not a strange dialect.

Richard P. Gabriel echoed a related concern: macros encourage people who are not good at language design to do something equivalent to language design, with effects that are too powerful.

## Do These Reasons Hold Up Anymore?

### It Has Never Been Easier to Understand Code

Today, you aren't reliant on finding a local expert. You can use an LLM to help you gain understanding in the ways that fit how you learn — custom visualizations, demos, and increasingly specific questions.

### Understanding Each Bit of Code is Less Important Than It's Ever Been

Things have been changing drastically. If you can make code faster and better, even at the cost of readability to you, but the AI can work with it perfectly fine, why wouldn't you?

## Sweetener, Macros for TypeScript

AI makes it trivial to write macros. AI makes it trivial to understand complex macros. Debugging code has become easier. And AI-written code might benefit greatly from macros. Jimmy resurrects the SweetJs idea for TypeScript as **Sweetener**.

### Custom operators (pipe)

```
import { (|>) } from "./macros.sts" for syntax;

export const total = [1, 2, 3]
|> map((n) => n * 2)
|> reduce((sum, n) => sum + n, 0);
```

### Algebraic datatypes

```
data Tree<T> = Leaf() | Node(left: Tree<T>, value: T, right: Tree<T>);
```

### Control flow in TSX

```
export const list = (items: readonly Item[]) => (
  <ul>
    {each (items as item, index)}
      <li key={item.id}>{index}: {item.name}</li>
    {end}
  </ul>
);
```

## Why Care About Macros If I'm Not Reading the Code

Macros encode larger patterns and automatically make sure AIs follow them — helping tame inconsistency as codebases grow.

## Macros are not Enough

We have spent countless engineering hours building tooling, parsers, linters, type checkers, build tools, all because our languages don't give us the ability to do what we need. That's no longer the case. It is time that changed.