HackerPapers

HN 二十年,最值得读的论文。

从 Hacker News 2006 年以来的全部投稿里,挑出链接本身就是论文的帖子:arXiv、期刊、会议论文、技术报告。每篇附中文标题,讨论最热的那些再加上中文导读和高赞评论翻译。

从必读开始
  • 8,000+篇被 HN 讨论过的论文

Essential

必读 30 篇

在论文库里看全部精选

编辑精选里 HN 讨论最热的 30 篇,每篇都有中文导读。不知道从哪读起,就从这里开始。

  1. 正在载入论文…

Archive

论文库

点柱子按年份筛选。注:源数据里 2023 年的帖子分数记录不全,2026 年尚未过完,这两年收录偏少。

难度
排序

    About

    这些论文是怎么挑出来的

    1. 01

      全量扫一遍

      读取 Hacker News 自 2006 年以来的全部 446 万条链接投稿,找出指向 arXiv、期刊、会议、技术报告和学术 PDF 的帖子。

    2. 02

      只留论文本身

      由 AI 逐条判断,剔除介绍论文的新闻、博客和幻灯片,同一篇论文的多次投稿合并计算,并统计它在评论区被引用的次数。

    3. 03

      写导读、译评论

      讨论最热的 1,500 篇配上中文导读,并精选、翻译 HN 高赞评论。导读由 AI 生成,可能有误,请以原文为准。

    编程语言与软件工程2021cs.utah.edu

    Lisp 机器的体系结构

    Architecture of Lisp Machines (2008)

    进阶 · 约 55 分钟读完前置知识:Lisp 基础、计算机体系结构、垃圾回收

    读论文 HN 讨论
    150HN 得分
    57条评论

    导读

    这是一份 2008 年的讲义/综述 PDF,讲的是 Lisp 机器(专门为运行 Lisp 设计的硬件)的体系结构:包括带标签的数据表示、硬件支持的垃圾回收、运行时类型检查等,把 Lisp 运行时通常由软件承担的工作交给硬件。文中也回顾了这类机器在商业化上的命运:造价高昂,相对同期通用机器性能并不占优。

    HN 关注点:焦点在于:当年为 Lisp 专门设计硬件的思路,今天还能在哪些通用硬件特性(tagged memory、TLB 辅助的 GC 写屏障)里看到;以及“Lisp 还值得学吗”这类老争论。

    关键词 Lisp machinegarbage collectiontagged memorycomputer architecture

    HN 评论精选

    这几条评论里:质疑 1 补充 3

    补充补充技术细节:Lisp 机器的主要运行时开销来自 GC 写屏障和类型检查,而现代 MMU/TLB 与 RISC-V tagged memory 让这些技巧有望惠及 Java、Python 等语言;并指出文中漏提了更早的 KA-10。

    文中描述的 Lisp 实现只需要付出少量、但开销较高的运行时成本(否则 Lisp 完全可以编译成非常快的代码)。一是 GC 写屏障的成本,Solvobarro 想到用 MMU 翻转写位的方式在廉价硬件上巧妙地处理了这个问题;我认为再加一点 TLB 硬件,就能把这个技巧推广成适用于任何带 GC 语言(比如 Java)的分代收集器。另一个巧妙的做法是:除非碎片化太严重,否则跳过对象搬运——在现代内存模型下,压缩早就不是当年那回事了。第二个成本是运行时类型分析,RISC-V 规范支持 tagged memory,这能让 Lisp、Python 等语言大幅提速,现在有人在做带这个选项的芯片吗?今天的好处是很多语言在重新捡起 Lisp 当年验证过的想法,所以把这些语言提速也能顺带提速 Lisp 实现。附言:希望这篇文章能提到 KA-10(第一台 PDP-10),那才是真正第一台为 Lisp 设计的机器,它的汇编语言直接实现了一批 Lisp 原语。

    gumby查看英文原文

    The lisp implementations described here had a small number expensive runtime costs (otherwise lisp can, if you wish, be complied into very fast code). One was the cost of the gc memory barrier (cleverly managed for commodity hardware by using the mmu and toggling the write bits, I think thought up by Solvobarro). I think a slightly more sophisticated trick could be done with some extra TLB hardware to generalize this for generational collectors for any gc language, say Java. Another smart trick would be to skip transporting unless fragmentation got too bad. In a modern memory model compaction just isn’t what it used to be. A second one is runtime type analysis. With the RISC-V spec supporting tagged memory this could be speeded up tremendously for Lisp, Python et al. Is anyone dabbing chips with that option? The nice thing today is that a lot of languages are revisiting ideas originally shaken out by lisp, so speeding those languages up can speed up Lisp implementations too. Ps: wish this article has mentioned the KA-10 (first PDP-10) which was really the first machine designed with Lisp in mind and with an assembly language that directly implemented a number of lisp primitives.

    质疑质疑 Lisp 的实际用途与学习价值,引发“是否值得学 Lisp”的争论。

    说个不受欢迎的观点——也许只是我嫉妒 Lisp 程序员。但 Lisp 真的被用在什么实际的东西上吗?就算只是教学,学 Lisp 值得吗?学别的语言不是更实用?学 Lisp 难道不像学一门死语言,出了课堂就再也用不上?你在 Lisp 课上学到的东西,用一门更流行、更实用的语言不也能学到吗?

    eric4smith查看英文原文

    Unpopular opinion here - and maybe it’s because I’m jealous of the Lispers. But is Lisp used for anything real? I mean, even teaching - is it worth it to learn lisp? Aren’t other languages more practical to learn? Isn’t learning lisp like learning a a dead language that once you leave the lisp class you’ll never use again? Wouldn’t you learn the exact same things you learned in lisp using a more widely used (practical)language?

    补充点出 Lisp 机器失败的核心原因:贵且慢。

    Lisp 机器是个有意思的想法。可惜它们非常昂贵,而且和当时的其他机器相比性能相当慢。

    aliasEli查看英文原文

    Lisp machines were an interesting idea. Unfortunately they were very expensive and fairly slow compared to other machines at the time.

    补充提议用 FPGA 复刻一台 Lisp 机器来玩。

    不知道有没有人想组队用 FPGA 做一个出来?我知道已经有人做过了,但听起来挺好玩。

    analognoise查看英文原文

    I don't suppose anyone wants to team up to try to build one for an FPGA? I know it's been done, but it sounds like fun.

    相关资源

    从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。

    代码

    历次讨论

    同领域还值得读

    1. Google 的软件工程(2017)

      Software Engineering at Google (2017)

      介绍了 Google 的软件工程实践,包括其单一代码库(monorepo)、几乎全部开发在主干进行而非分支、代码审查、构建系统 Blaze、协议缓冲区等工具与流程,并讨论了频繁重…

      编程语言与软件工程2017 · 1,127 分 · 465 评 · 引用 15入门 · 约 45 分钟编辑精选
    2. Peter Naur:编程作为理论构建 (1985)

      Peter Naur – Programming as Theory Building (1985)

      Peter Naur 1985 年的经典论文《Programming as Theory Building》提出:编程的本质不是写代码或文档,而是在程序员头脑中构建对程序及其运行…

      编程语言与软件工程2016 · 629 分 · 74 评入门 · 约 45 分钟编辑精选
    3. SciPy 1.0:Python 科学计算的基础算法

      SciPy 1.0: fundamental algorithms for scientific computing in Python

      这篇发表于 Nature Methods 的论文介绍了 SciPy 1.0——Python 科学计算生态的基石库,涵盖其核心算法模块(优化、积分、插值、线性代数等)、软件架构与社…

      编程语言与软件工程2020 · 387 分 · 98 评入门 · 约 45 分钟编辑精选
    4. Lisp 的历史(1979)

      History of Lisp (1979)

      这是 Lisp 发明者 John McCarthy 于 1979 年为 HOPL(编程语言史)会议撰写的回顾文章,讲述 Lisp 的起源、设计动机与早期演进,文中也涉及 if 表…

      编程语言与软件工程2018 · 352 分 · 44 评入门 · 约 45 分钟编辑精选
    5. 使用 NumPy 进行数组编程

      Array Programming with NumPy

      这篇 Nature 文章介绍 NumPy 的数组编程模型及其在科学计算中的核心作用:以 ndarray 为中心,通过向量化操作让 Python 高效处理多维数组。

      编程语言与软件工程2020 · 318 分 · 134 评入门 · 约 40 分钟编辑精选

    打赏支持

    打赏二维码

    觉得有用,请作者喝杯咖啡。

    WeChat

    关注向阳乔木

    微信公众号「向阳乔木推荐看」

    微信公众号「向阳乔木推荐看」二维码

    微信扫一扫;在微信里打开本页时,长按二维码识别。