We Should Be Able to Change Our Languages

Rust has been a practical experiment in macros for ten years now. I think it is safe to say the results are in: macros are great, and you just needed to have a better style of macros. Making and using something like `tokio::select!` in C-style macros is miserable, but `tokio::select!` is easy to use and understand in Rust.

At the risk of being a bit of a douchebag, it seems like nearly every tech opinion piece I read now boils down to "things used to be hard but they aren't anymore because LLMs can understand things faster than we can, so can ignore/change fundamentals!"

I didn't really find the argument convincing the first time and I don't really find it convincing now.

That said, with regards to macros, I actually do agree that the fear against them is broadly overblown. I have seen scary terrible horrifying macro soup in Clojure, but that has generally been outlier cases. Something like core.async abuses the hell out of macros, and despite that I think it very often increases readability and understanding of the language.

Not sure what this guy is on about. Languages with extensible syntax (through macros, through term rewriting, through intrusive function like decorators) have always been available, though notably less popular. Languages also can support extensible features through reflection: runtime inspection of structure of user-defined types.

- Any language with bicameral syntax (the lisps, etc)

- Rebol and Red

- Smalltalk, Self, etc.

People tend to not like these for most programming problems due to the eventual maintenance burden and the steep up front cost of becoming competent with them. But the title and thesis of this post is a bit of a head scratcher: we've always been able to change languages designed to be changed, and mainstream high level language no. 2, Lisp, was one such language. As always, whether or not a language supports macros or some general metaprogramming facility is a design tradeoff both for the complexity of the compiler and the implicit complexity of the codebase (knowing that the language doesn't prevent you from defining new operators with semantics that may go counter to the intuition employed in the base language).

Someone just asked for Common Lisp and Smalltalk.

Basic argument:

I want it because LLMs make it easy to do without having to think.

Moving from Java to Kotlin was a breath of fresh air; sometimes a language change genuinely unlocks productivity.

My last project needed Rust for one module, but the rest was Go. Felt silly rewriting core logic just to stay unified.

Not a single mention of Chesterton's Fence. Was this really written for HN, then?