Jimmy Miller：我们应能自定义编程语言
We Should Be Able to Change Our Languages
编程语言常被视为不可更改的神圣存在，但Jimmy Miller认为，在AI时代，这种观念该改变了。过去，人们因担心宏（macros）导致代码难以调试而抵制自定义语言特性。然而，如今LLM能轻松解释复杂代码，理解每一行细节已不再关键。作者指出，AI生成的代码常因缺乏统一规范而显得杂乱，而宏恰恰能编码大型模式，帮助AI遵循约定。为此，他复活了SweetJs理念，推出了针对TypeScript的Sweetener工具，让开发者能自定义管道运算符、代数数据类型等语言结构。这不仅是技术升级，更是对编程表达自由的重新探索。
在软件日益灵活、可塑、可编辑的世界里，我们的编程语言却抗拒这种变化。
HN 评论区
36- flowerbreeze
我觉得能在语言中定义额外规则是个合理的功能，有时能让生活轻松很多，但我觉得如果通过文本宏来实现，而不是重写底层的程序图并处理所有约束，那就会引发大多数问题。
程序图重写当然更复杂，但在定义可接受的输入方面能更明确，而且比把问题抛给编译器或解释器的下一步处理更具防御性。
另一个问题是，大多数 IDE 都没有提供展开宏（或类似）的选项来查看重写后的部分（或者我没见过它们这么做），所以观察最终代码的样子需要额外的步骤。在某些方面，它类似于函数，但大多数语言的函数都有明确定义的输入/输出结构，而宏则会根据输入做一些意想不到的事情。
- Retr0id
宏（以及类似的语言特性）的主要问题是，它们把每个代码库都变成了自己的 DSL。如果做得恰到好处，代码会更易读，但对于新加入代码库的人来说，仍然存在学习成本——他们需要先掌握你的 DSL 才能开始高效工作。
LLM 可能会让你感觉不到这个开销，但它肯定还是存在的？我更希望我的 token 用在解决实际任务上，而不是去搞懂自定义语法（并且在每个新的上下文窗口里重新学习一遍）。
- pie_flavor
Rust 在宏方面已经进行了十年的实践实验。我想可以安全地说，结果已经很明显了：宏很棒，只是你需要一种更好的宏风格。在 C 风格的宏中创建和使用类似 `tokio::select!` 的东西是痛苦的，但在 Rust 中，`tokio::select!` 却很容易使用和理解。