We Should Be Able to Change Our Languages
Jimmy H. Miller introduces Sweetener, a TypeScript macro library, arguing that LLMs eliminate traditional readability concerns against customizing programming languages with custom syntax.
summary is enough The core thesis relies on a controversial premise about LLM code comprehension, and the comment thread provides much stronger pushback against custom domain-specific languages.
summary
Programming languages should be infinitely customizable through powerful macros, bypassing committee-driven feature creep. The text introduces Sweetener, a new tool adding custom operators and algebraic datatypes to TypeScript. The piece contends that traditional objections about code readability no longer apply because LLMs can easily parse custom syntax. Critics strongly push back against this premise, warning that unconstrained DSLs create massive onboarding friction and maintenance debt for human engineers.
key points
- Sweetener is an experimental macro tool for TypeScript enabling custom operators, pattern matching, and algebraic datatypes without language committee approval.
- The post claims traditional arguments against control flow macros are obsolete because LLMs make complex code easy to understand.
- Respondents heavily criticize the thesis, arguing that turning every codebase into a bespoke DSL severely harms human maintainability.
who should read it
TypeScript developers, language designers, and software engineers interested in metaprogramming and AI-assisted development.
discussion skeptical
consensus
Most participants reject the thesis, arguing that custom DSLs and heavy macros create severe onboarding and maintenance burdens for human developers regardless of AI assistance.
pushback
A few participants suggest that macros can be effective when designed well, pointing to Rust, while others note that languages like Lisp and Forth pioneered extensible syntax decades ago with similar trade-offs.
The main problem with macros (and similar language features) is that they turn every codebase into its own DSL. When done tastefully it makes the code more readable, but there's still an overhead for newcomers to the codebase - they need to learn your DSL before they can be productive.
LLMs may make this overhead less visible to you, but surely it's still there? I'd rather more of my tokens went towards solving the actual task at hand, vs figuring out a custom syntax (and re-learning it on every fresh context window).
It pinpoints the core issue that macros turn every codebase into a unique DSL, imposing high cognitive overhead on newcomers that LLMs merely mask rather than solve.
Generated by an LLM from the article and thread. Check the sources before relying on it.