We Should Be Able to Change Our Languages

This argues that programmers should be able to modify and extend their languages directly rather than waiting on committees or layering complex build tools and conventions. Common objections - that macros and custom constructs make code unreadable, obscure semantics, and hinder newcomers - are acknowledged (citing classic criticisms about flow-control macros), but rejected as outdated. Large codebases already contain lots of inscrutable code, and modern tools - particularly large language models - make understanding unfamiliar constructs trivial. Because humans no longer must read every line to work with or change code, the cost of richer, localized language design has fallen, and allowing teams to shape syntax and semantics can yield more expressive, maintainable solutions.

To demonstrate practicality, a macros-for-TypeScript tool called Sweetener is introduced as a successor to SweetJs, showing concrete capabilities: custom operators like a pipe (|>) declared with fixity and rewrite rules, algebraic data types with pattern matching and exhaustiveness checking, and TSX-level control-flow constructs for cleaner templates. Macros can encode project-wide patterns so AIs and humans alike produce consistent code, tame AI-generated inconsistencies, and let teams prototype novel language features without writing compilers. The piece ends by arguing that empowering programmers with in-language extensibility would reduce the sprawling externals (linters, build steps, test runners) created to compensate for rigid languages.