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

    编程语言与软件工程2016cs.yale.edu编辑精选

    Haskell vs. Ada vs. C++:软件原型开发生产力实验(1994)

    Haskell vs. Ada vs. C++ an Experiment in Software Prototyping Productivity (1994)

    入门 · 约 30 分钟读完前置知识:编程语言基础、函数式编程概念

    读论文 HN 讨论
    203HN 得分
    154条评论
    4次投稿

    导读

    这是耶鲁大学 1994 年的一份技术报告,用同一个软件原型任务对比 Haskell、Ada、C++ 等语言的开发效率,主要以代码行数和开发时间衡量,结论是 Haskell 方案远为简短。它在编程语言圈被反复引用和争论,但评论者指出对比并不严谨:Haskell 版本由作者之一、著名 Haskell 程序员 Mark P. Jones 亲自编写,其他语言的实现甚至没有运行,比较维度基本只有 LOC。

    HN 关注点:它是“函数式语言更高效”论战中流传最广的经典弹药,但 HN 读者更关注其方法论缺陷和作者偏见,以及这类跨语言生产力实验到底该怎么做。

    关键词 HaskellAdaC++software prototyping语言生产率

    HN 评论精选

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

    质疑质疑论文存在作者偏见:只比 LOC、其他实现未运行,结论不可靠。

    这篇论文明显是在推销 Haskell。主要作者写的就是 Haskell 版本,其他原型他们根本没运行,除了代码行数之外没做任何像样的比较就下了结论。我自己喜欢 Haskell,但这篇论文在科学诚实性上做得很差。

    ysleepy查看英文原文

    Hm, this paper is pretty obviously promoting Haskell. The main authors wrote the haskell variant, did not even execute the other prototypes and make conclusions without any sort of comparison except LOC. I like haskell, but this paper is doing a poor job of representing scientific honesty.

    亲历亲历者回忆:Haskell 版出自高水平程序员之手,人的因素盖过了语言因素。

    有人(我记得是 John C. Peterson)在去年的 Paul Hudak 纪念研讨会上提到过这篇论文。他的评价是:这个比较不公平,因为那个 Haskell 程序是 Mark P. Jones 写的——无论用什么语言,他的水平都足以碾压对手。

    vilhelm_s查看英文原文

    Someone (I think John C. Peterson) mentioned this paper at the Paul Hudak memorial symposium last year. His comment was the that the comparison was unfair, because the Haskell program was written by Mark P. Jones, who was a good enough programmer to outshine his competitors no matter what language. :)

    补充提出改进实验设计:把“可理解性/可维护性”也纳入测量,分离程序员与文档员。

    如果让我来做这个实验,我会为每种语言配两位专家:程序员 P 和文档员 D,两人不许交流。P 只能写代码,不许有任何注释或文档。D 不许看问题描述,只能拿到输入数据(附数据含义说明)和 P 写的代码,靠自己对这门语言的掌握推断代码在做什么、反推出要解决的问题。然后衡量 P 耗时、D 耗时、代码规模、代码实际解决问题的程度,以及 D 反推出的规格与原始规格的吻合度。这样才能得出有意义的结论:比如某个方案很短、开发很快,但要花大力气才能看懂——这在一次性脚本场景下可以接受,而长期生产代码通常更希望 D 能轻松读懂。

    kazinator查看英文原文

    Here is how I would run this experiment. For each language, I would have two experts in that language. Call them P and D: programmer and documenter. They would not be permitted to communicate. P would be required to write strictly code, without a single comment or a shred of documentation. D would not be permitted to view the problem description: only the input data (along with documentation describing what the data means) and the code written by P. D would have to determine what the code is doing and specify the problem being solved, relying on his or her expertise in the implementation language to unravel how the code is treating the input data, and hence what is its meaning. Then evaluate the time spent by P, the time spent by D, the size the code, and the degree to which the code actually solves the problem and the degree to which D's documentation actually reverse-engineers the specification not revealed to D. Then we could say meaningful things: like a given solution is very small and was developed quickly, but it took great effort to unravel what it's doing. That's not bad: there are situations when that is acceptable, namely the development of one-off solutions that will never need to be understood or maintained, and which are needed ASAP. Situations would also reveal themselves when the program takes long, and isn't particularly short, but is a breeze for D to understand. Usually we would prefer that situation in permanent production code. The all round winner would be: small code written by P in a short amount of time, quickly reverse-engineered by D to recover the spec. (With bonus points for time performance, small memory use, etc). There is also a degree of realism in this setup. How often are we called upon to understand some code which is utterly undocumented? That's when we feel the differences in languages, programming approaches and styles.

    相关资源

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

    关注向阳乔木

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

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

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