编程语言与软件工程2020microsoft.com编辑精选
Perceus：带复用机制的免垃圾回收引用计数
Perceus: Garbage Free Reference Counting with Reuse
进阶 · 约 70 分钟读完前置知识：引用计数与内存管理基础、函数式语言编译与求值策略、类型系统/线性类型初步
导读
这篇论文提出 Perceus，一种编译期精确引用计数加内存复用（reuse）的技术，目标是无需垃圾回收器就实现内存管理，并在 Koka 语言中实现。核心在于把释放与复用结合，配合快慢路径分离的计数操作，做到"无垃圾"的引用计数。
HN 关注点：其精巧的引用计数实现细节（负计数标记共享对象、快慢路径），以及是否必须搭配严格的效果系统这一实用性质疑。
后来怎么样
Perceus 的编译期精确引用计数与复用方案被 Lean 4 采纳为其运行时的内存管理基础，也使 Koka 的无 GC 内存管理进入实用阶段，并推动了无垃圾回收的函数式语言编译研究。
HN 评论精选
这几条评论里：质疑 2 补充 1
补充拆解实现细节：负计数标记线程共享对象，快慢路径分离以优化释放开销。
这篇论文值得一读；一个对很多人有用的实现细节是它对引用计数的用法：负的引用计数用来表示线程共享的对象。当 refcount > 1 时，释放对象走快速路径，只需一次分支、执行非原子的减法；慢速路径才处理释放内存、原子计数修改，以及用溢出加一编码的"粘性"对象标志。
vnorilo查看英文原文
This paper is worth reading; an implementation detail that may be useful to many is their use of reference counting: negative refcount is used to indicate thread-shared objects. Releasing objects goes fast path with a single branch when refcount > 1, performing a non-atomic decrement. The slow path handles freeing memory, atomic counter mutation, and a sticky object flag encoded as overflow-by-one.
质疑质疑 Rust 的 NLL 是否已能解决作用域引用计数的 drop 时机问题。
乍看之下确实很有意思。一个想法：论文提到 C++ shared_ptr、Rust 的 Rc、Nim 都用"作用域生命周期"引用计数。那么 Rust 的非词法生命周期（NLL）不能解决这个问题吗？也就是说，2.2 节开头示例里 xs 的 drop 必须发生在作用域末尾，而不是 map 之后？我本以为 ys 不从 xs 借用任何东西，drop 可以在 map 之后立即插入？也许是我一大早脑子还没转过来。
parley查看英文原文
This does seem very interesting, at first glance. One thought: > These “scoped life-time” reference counts are used by the C++ shared_ptr⟨T⟩(calling the destructor at the end of the scope), Rust’s Rc⟨T⟩(using the Drop trait), and Nim (using a finally block to call destroy) So Rust's non-lexical lifetimes doesn't remedy this? Meaning the actual drop of xs needing to occur at the end of the example in the beginning of section 2.2, as opposed to right after the map. I would have thought that ys borrows nothing from xs, and the drop can be inserted right after map? Perhaps it's too early in the morning for thinking for me.
质疑担心该技术所需的效果系统注解会带来繁琐的传播负担。
令人印象深刻。我想知道，任何采用这些技术的语言是否也必须使用如此严格的效果系统——看起来是这样。他们的实现要求所有有副作用的函数（抛异常、打印日志等）都加注解。我不清楚这些函数的调用者是否也需要注解，但我猜需要。如果是这样，那是个相当繁琐的限制。虽然我喜欢显式，但给一个深层、被频繁调用的函数改签名（比如临时加调试日志）会牵动大量其他代码。
christophilus查看英文原文
This is impressive. I wonder if any language that used these techniques would also have to use such a rigorous effect system. It seems so. Their implementation requires annotations on all functions which are effectful (throw exceptions, log to the console, etc). What wasn’t clear to me was whether or not the callers of those functions also need to be annotated, but I presume they do. If so, that’s a pretty tedious limitation. While I like explicitness, changing the signature of a deep, oft-called function (e.g. to add temporary debug logging) requires changing a lot of other code.
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2020Hacker News 讨论帖153 分 · 44 评
同领域还值得读
Google 的软件工程（2017）
Software Engineering at Google (2017)
介绍了 Google 的软件工程实践，包括其单一代码库（monorepo）、几乎全部开发在主干进行而非分支、代码审查、构建系统 Blaze、协议缓冲区等工具与流程，并讨论了频繁重…
编程语言与软件工程2017 · 1,127 分 · 465 评 · 引用 15入门 · 约 45 分钟编辑精选Peter Naur：编程作为理论构建 (1985)
Peter Naur – Programming as Theory Building (1985)
Peter Naur 1985 年的经典论文《Programming as Theory Building》提出：编程的本质不是写代码或文档，而是在程序员头脑中构建对程序及其运行…
编程语言与软件工程2016 · 629 分 · 74 评入门 · 约 45 分钟编辑精选SciPy 1.0：Python 科学计算的基础算法
SciPy 1.0: fundamental algorithms for scientific computing in Python
这篇发表于 Nature Methods 的论文介绍了 SciPy 1.0——Python 科学计算生态的基石库，涵盖其核心算法模块（优化、积分、插值、线性代数等）、软件架构与社…
编程语言与软件工程2020 · 387 分 · 98 评入门 · 约 45 分钟编辑精选Lisp 的历史（1979）
History of Lisp (1979)
这是 Lisp 发明者 John McCarthy 于 1979 年为 HOPL（编程语言史）会议撰写的回顾文章，讲述 Lisp 的起源、设计动机与早期演进，文中也涉及 if 表…
编程语言与软件工程2018 · 352 分 · 44 评入门 · 约 45 分钟编辑精选使用 NumPy 进行数组编程
Array Programming with NumPy
这篇 Nature 文章介绍 NumPy 的数组编程模型及其在科学计算中的核心作用：以 ndarray 为中心，通过向量化操作让 Python 高效处理多维数组。
编程语言与软件工程2020 · 318 分 · 134 评入门 · 约 40 分钟编辑精选