思考与写作graydon2.dreamwidth.org
“接下来呢？”
“What next?”
2017 — 2021，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 Graydon Hoare（Rust 作者）以“What next?”为题的文章，讨论编程语言设计下一步还能往哪里走，其中首先谈到 ML 风格模块等方向。文中更像一份对语言特性的反思与待办清单，梳理他认为仍未被很好解决的设计空间。
为什么经久不衰：出自 Rust 作者之手，对语言设计的第一手反思具体而克制；它提出的模块、范式混合、编译期计算等问题，今天仍是语言社区反复争论的经典难题。
HN 评论精选
ML 风格模块表达力强、可组合，还能同时处理静态与动态组件，是值得学习的抽象机制。
Grayson 对“下一步是什么”的第一个回答是“ML 模块”，这是很少有人亲自用过的一种语言特性。这里的 ML 风格模块有精确定义（不同于常见语言里只是把一些相关标识符堆在一起的 module）。ML 模块极难用几句话讲清有多好：它很好地抓住了抽象的本质，表达力强，而且可以组合——你甚至可以写从模块到模块的函数。更厉害的是模块同时有运行时和编译期组件，一个函数能同时操作静态和动态的东西，这让创建抽象变得很轻松。想了解可读 Danny Gratzer 的《A Crash Course on ML Modules》，再学 SML 或 OCaml 试试。
jez查看英文原文
Grayson's very first answer to "what's next" is "ML modules," a language feature probably few people have experienced first hand. We're talking about ML-style modules here, which are quite precisely defined alongside a language (as opposed to a "module" as more commonly exists in a language, which is just a heap of somewhat related identifiers). ML modules can be found in the mainstream ML family languages (Standard ML, Ocaml) as well as some lesser known languages (1ML, Manticore, RAML, and many more). It's really hard to do justice explaining how amazing modules are. They capture the essence of abstraction incredibly well, giving you plenty of expressive power (alongside an equally powerful type system). Importantly, they compose; you can write functions from modules to modules! (This is even more impressive than you think: modules have runtime (dynamic) AND compile time (static) components. You've certainly written functions on runtime values before, and you may have even written functions on static types before. But have you written one function that operates on both a static and a dynamic thing at the same time? And what kind of power does this give you? Basically, creating abstractions is effortless.) To learn more, I recommend you read Danny Gratzer's "A Crash Course on ML Modules"[1]. It's a good jumping off point. From there, try your hand at learning SML or Ocaml and tinker. ML modules are great! [1]: https://jozefg.bitbucket.io/posts/2015-01-08-modules.html
混用异步/阻塞、函数式/命令式等范式会带来复杂性和死锁，复杂类型系统未必是答案。
我们正撞上的一个大问题是同一门语言里混用不兼容的范式。纯回调（如 JavaScript）没问题，纯线程加锁也没问题，但同一程序里同时有 async/await 和阻塞锁会很快变得痛苦并导致死锁，尤其当两套系统互不理解对方的锁（Go 试图用统一锁做对，Python 没有）。纯函数式和纯命令式各自没问题，混在一起就复杂（Rust 可能过度了）。更复杂的类型系统未必有用：SOAP/XML schema 就被更随意的 JSON 取代了；框架/库的接口方向也仍不对称；编译期用户代码（泛型/模板）越来越复杂，图灵完备也没帮上忙。
Animats查看英文原文
One big problem we're now backing into is having incompatible paradigms in the same language. Pure callback, like Javascript, is fine. Pure threading with locks is fine. But having async/await and blocking locks in the same program gets painful fast and leads to deadlocks. Especially if both systems don't understand each other's locking. (Go tries to get this right, with unified locking; Python doesn't.) The same is true of functional programming. Pure functional is fine. Pure imperative is fine. Both in the same language get complicated. (Rust may have overdone it here.) More elaborate type systems may not be helpful. We've been there in other contexts, with SOAP-type RPC and XML schemas, superseded by the more casual JSON. Mechanisms for attaching software unit A to software unit B usually involve one being the master defining the interface and the other being the slave written to the interface. If A calls B and A defines the interface, A is a "framework". If B defines the interface, B is a "library" or "API". We don't know how to do this symmetrically, other than by much manually written glue code. Doing user-defined work at compile time is still not going well. Generics and templates keep growing in complexity. Making templates Turing-complete didn't help.
软件应以富数据模型而非纯文本文件存储，编辑器可按上下文提供多视图并减少语法噪音。
我认为房间里的大象是超越纯文本（projectional editor、基于模型的编辑器）。把软件表示成一堆文件夹里的纯文本文件，很多问题直接由此而来；我们“花哨”的编辑器和 intellisense 能力有限，语法脆弱、解析困难拖慢了语言演化。把软件当作数据模型可以去掉大量样板和噪音，让编辑器按上下文显示不同视图（调试模式、文档模式、开发模式可以很不一样），也能任意把东西拉进一个视图。“一堆文件放在文件夹里”的思维方式自带很多包袱和假设，会迫使我们做不一定有利的事，比如把东西拆得比想要的更碎。
borplk查看英文原文
I'd say the elephant in the room is graduating beyond plaintext (projectional editor, model-based editor). If you think about it so many of our problems are a direct result of representing software as a bunch of files and folders with plaintext. Our "fancy" editors and "intellisense" only goes so far. Language evolution is slowed down because syntax is fragile and parsing is hard. A "software as data model" approach takes a lot of that away. You can cut down so much boilerplate and noise because you can have certain behaviours and attributes of the software be hidden from immediate view or condensed down into a colour or an icon. Plaintext forces you to have a visually distracting element in front of you for every little thing. So as a result you end up with obscure characters and generally noisy code. If your software is always in a rich data model format your editor can show you different views of it depending on the context. So how you view your software when you are in "debug mode" could be wildly different from how you view it in "documentation mode" or "development mode". You can also pull things from arbitrarily places into a single view at will. Thinking of software as "bunch of files stored in folders" comes with a lot baggage and a lot of assumptions. It inherently biases how you organise things. And it forces you to do things that are not always in your interest. For example you may be "forced" to break things into smaller pieces more than you would like because things get visually too distracting or the file gets too big. All of that stuff are arbitrary side effects of this ancient view of software that will immediately go away as soon as you treat AND ALWAYS KEEP your software as a rich data model. Hell all of the problems with parsing text and ambiguity in sytnax and so on will also disappear.
编译器应重视自动数据布局和结构变换，因为内存访问/缓存是主要瓶颈。
我念念不忘但常被忽略的语言/编译器技术问题又没被提到：数据布局优化。控制流和计算优化已经让高层抽象几乎不付性能代价，但自动进行（甚至只是辅助）程序员做性能工作时每天都要做的数据结构变换——比如 AoS 转 SoA、压缩对象引用、按范围分析缩小字段、把一起使用的数据扁平化/反规范化、把冷字段改成间接查找、按调用点输入数据编译不同版本——几乎闻所未闻。考虑到大家都同意内存访问和缓存占用是当前主要性能瓶颈，这很令人费解。
fulafel查看英文原文
Again my pet ignored language/compiler technology issue goes unmentioned: data layout optimizations. Control flow and computation optimizations have enabled use of higher level abstractions with little or no performance penalty, but at the same time it's almost unheard of to automatically perform (or even facilitate) the data structure transformations that are daily bread and butter for programmers doing performance work. Things like AoS->SoA conversion, compressed object references, shrinking fields based on range analysis, flattening/dernormalizing data that is used together, converting cold struct members to indirect lookups, compiling different versions of the code for different call sites based on input data, etc. It's baffling considering that everyone agrees memory access and cache footprint are the current primary perf bottlenecks, to the point that experts recommend considering on-die computation is free and counting only memory accesses in first-order performance approximations.
历次讨论
同类还值得读
保持你的身份认同足够小
Keep Your Identity Small (2009)
Paul Graham 2009 年的一篇短文：人一旦把某个话题当成自己身份的一部分（宗教、政治、编程语言皆然），讨论就会退化成站队和争吵，因为此时争论的不再是事实，而是"我是谁…
思考与写作上首页 5 次 · 2009–2021paulgraham.com编辑精选苏格拉底式教学法：通过提问而非讲授来教学
The Socratic Method: Teaching by Asking Instead of by Telling
记录了作者用纯提问的方式，引导一群小学生从零推导出二进制计数法的课堂实验，展示了苏格拉底式教学法的惊人效果。
思考与写作上首页 5 次 · 2011–2022garlikov.com你不能说的话
What You Can't Say (2004)
Paul Graham 2004 年的经典文章，探讨那些因道德时尚而不能公开说出的观点。
思考与写作上首页 5 次 · 2014–2022paulgraham.com编辑精选龙暴君的寓言（2005）
The Fable of the Dragon-Tyrant (2005)
哲学家 Nick Bostrom 于 2005 年写的一则寓言：一条每天吞噬数千人的巨龙（隐喻死亡与衰老）长期被人类当作不可抗拒的自然规律接受，直到有人提出并最终用导弹将其杀死，…
思考与写作上首页 5 次 · 2009–2021nickbostrom.com编辑精选现实有着惊人的细节量
Reality has a surprising amount of detail (2017)
2017 年的博文指出，现实远比我们以为的充满细节：我们习惯用简化的心智模型看世界，直到真正动手做事（比如作者举的造楼梯例子）才发现处处是未曾预料的细节。
思考与写作上首页 4 次 · 2018–2025johnsalvatier.org编辑精选