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 生成,可能有误,请以原文为准。

    编程语言与软件工程2014thocp.net编辑精选

    编程能否从冯·诺依曼风格中解放出来?(1977)

    Can Programming Be Liberated from the von Neumann Style? (1977)

    入门 · 约 60 分钟读完前置知识:函数式编程基础、冯·诺依曼架构

    读论文 HN 讨论
    177HN 得分
    104条评论
    2次投稿

    导读

    这是 John Backus 1977 年的图灵奖演讲:他批评传统冯·诺依曼式编程把思维束缚在'逐条指令改变状态'的模型上,主张用代数性质的函数式编程(他提出的 FP 系统)让程序可以像数学对象一样被推导和变换。文章是函数式编程历史上最具影响力的宣言之一。

    HN 关注点:这篇近五十年前的演讲至今仍被反复讨论,因为它提出的问题——冯·诺依曼瓶颈与函数式编程能否解放程序员——在多核时代和函数式语言兴起的背景下依然没有定论。

    关键词 函数式编程冯·诺依曼瓶颈BackusFP图灵奖演讲

    后来怎么样

    这篇图灵奖演讲成为函数式编程历史上最具影响力的宣言之一,FP 系统直接启发了后续的函数式语言研究(如 FL、J 语言),并推动了程序代数变换与 point-free 风格的发展。

    HN 评论精选

    这几条评论里:支持 1 质疑 1 补充 1 亲历 1

    亲历以 Joy 语言实践佐证:程序代数变换的想法确实可行且强大

    我认为他提出的'通过对程序做代数/形式化操作来推导和变换程序'这一想法值得更多关注。我用 Joy(类似 Backus 的 FP 和 Conal Elliott 的 point-free Haskell)做实验时,很多在其他记法下非常棘手的元编程都变得很直接,并给出了二次方程定义推导、递归组合子、生成器程序等示例链接。

    carapace查看英文原文

    FWIW, I think the idea he presents of performing algebra (or other formal syntactic or semantic operations) to derive and transform programs deserves more attention than it seems to get. I was doing some experiments with Joy ( https://joypy.osdn.io/ ) and some meta-programming that would have been pretty gnarly in most other notations was very straightforward: https://joypy.osdn.io/notebooks/Quadratic.html#derive-a-definition https://joypy.osdn.io/notebooks/Recursion_Combinators.html#derivation-of-hylomorphism-combinator https://joypy.osdn.io/notebooks/Generator_Programs.html#making-generators https://joypy.osdn.io/notebooks/Newton-Raphson.html#finding-consecutive-approximations-within-a-tolerance Joy is similar to Backus' FP and to the point-free Haskell of Conal Elliot's "Compiling to categories" http://conal.net/papers/compiling-to-categories/ https://joypy.osdn.io/notebooks/Categorical.html

    补充冯·诺依曼架构本身(共享总线)才是问题根源,硬件也该被解放

    不知道有没有人注意到:人们先发明了代码与数据共用一条总线的架构,随后就因'把数据写到代码区、把数据当代码执行'而遇到无穷问题,最后只能靠禁止数据与代码混写来打补丁。所以,也许该被解放的是计算机本身,而不是编程——应该摆脱单总线/单流水线。

    aasasd查看英文原文

    I wonder if anyone noticed how people first came up with the architecture of a single bus for data and code and how they then had endless problems due to writing data where code should be and executing data as code. And they plug the problems by forbidding to write data and code in the same place and to read data as code (afaik). So yeah, should maybe computers be liberated from the single pipeline?

    支持多核时代串行架构成为瓶颈,应重拾函数式与数据流编程

    冯·诺依曼演进路线成就伟大,但 MHz 免费午餐结束后,其串行本质正在拖后腿。函数式和数据流编程等许多分支仍几乎未被工业界探索,值得重新评估。Ivan Sutherland 说得最好:并发本质上并不难,难是我们自己被串行的冯·诺依曼架构束缚了。

    slacka查看英文原文

    While we have achieved greatness with the Von Neumann evolutionary line, now that the Mhz free lunch is ending, it’s time for us to recognize that its sequential nature is holding us back. There are still many branches of Computer Science that researchers and industry have barely explored. We need to reevaluate these other branches like Functional and Dataflow programming. Ivan Sutherland explains it best when he says that concurrency is not fundamentally hard. The problem is that we constraining ourselves to the fundamentally sequential Von Neumann architecture. https://www.youtube.com/watch?v=jR9pAaQlVRc#t=267

    质疑工业界实际偏好'带 lambda 的 C',函数式风格难以普及

    我觉得工业界并不真想让函数式风格占主导。OCaml 兼具高抽象层次和出色性能,Lisp 速度稍逊但能把大脑带到另一个维度。但实践中人们似乎只想要 Go 那种'带 lambda 的 C'。

    cheepin查看英文原文

    I feel like "industry" doesn't really want functional style programming to take over. Languages like OCaml provide really great speed while having also utilizing a relatively high abstraction level, while Lisp may not have as much speed but it takes your brain on a journey to another dimension. However, in practice, people seem to just want "C with Lambdas" languages like Go.

    相关资源

    从这篇论文所有 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

    关注向阳乔木

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

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

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