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

    编程语言与软件工程2016spinroot.com编辑精选

    The Power of Ten:开发安全关键代码的十条规则

    The Power of Ten – Rules for Developing Safety Critical Code

    入门 · 约 30 分钟读完前置知识:C 语言基础、软件工程基础

    读论文 HN 讨论
    287HN 得分
    149条评论

    导读

    这是 NASA JPL 提出的编写安全关键 C 代码的十条规则(如避免复杂控制流、限制动态内存、高断言密度、限制预处理器的使用等),旨在通过约束编码风格降低软件缺陷率。文中每条规则都有降低开发成本和风险的量化论证。

    HN 关注点:这套经典编码规范本身的价值,以及它能否或应否推广到非安全关键领域(如 JavaScript、普通项目)。

    关键词 NASA安全关键代码C语言编码规范

    后来怎么样

    JPL 的这套 C 编码规则成为安全关键软件开发的知名参考标准,被广泛引用于高可靠性 C 代码规范和静态分析工具的规则设计中。

    HN 评论精选

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

    支持认可规则整体合理,但认为禁止复杂宏会带来代码重复这一更大风险

    在我看来 RankRed 标为'规则5——低断言密度'的表述有误,应为'高断言密度'——该规则要求每个函数至少两个断言(且按规则4函数应很短)。这些建议总体不错,与我写高可靠性 C 代码时遵循的规则基本一致。唯一保留意见是'规则8——限制预处理器'禁止所有复杂宏用法:在 C 中,避免大量代码重复的常见做法就是把事实表存在宏定义里,再用预处理器展开到各处使用。此时要在复杂宏的风险与代码重复的风险(维护者改了一处却漏改另一处)之间权衡。我的经验是代码重复的风险非常高,值得冒险用复杂宏来避免,且可通过结构化方式编写宏来控制复杂度。

    garethrees查看英文原文

    It looks to me as though the recommendation that RankRed has titled "Rule No. 5 — Low Assertion Density" would be better described as "High Assertion Density" — the recommendation is for a minimum of two assertions per function (and functions are supposed to be short per rule 4). The recommendations look good to me and (with one caveat) correspond to rules that I apply when writing C code with a high reliability requirement. My one caveat is in "Rule No. 8 – Limited Use of Preprocessor" which bans all complex uses of the preprocessor. The problem is that it is common in C to encounter situations where the only way to avoid lots of code duplication is to store a table of facts in a macro definition and use the preprocessor to expand those facts into the relevant bits of code in each place where they are used. So in these situations you face a trade-off between the risks due to complex preprocessor use, and the risks due to code duplication (namely, a maintainer might change a fact in one place where it is used but fail to change it in another). My experience is that the risks due to code duplication are very high, and so it's worth the risk of using complex preprocessor macros to avoid them. The risks can be mitigated by implementing the necessary macros in a structured way to keep the complexity under control: http://garethrees.org/2007/04/24/relational-macros/

    亲历亲历者指出 NASA 规范被过度套用到非安全关键项目的问题

    根据我的经验,NASA 软件工程要求最大的问题在于它们往往会向下渗透到非安全关键项目中。不过情况正在改善。

    thearn4查看英文原文

    Speaking from experience, the biggest problem with NASA's software engineering requirements (http://nodis3.gsfc.nasa.gov/displayDir.cfm?t=NPR&c=7150&s=2B) is the way that they tend to feed down into non-safety critical projects. It's getting better though.

    补充补充原始论文和 JPL 官方文档链接

    更详细描述并论证这些规则的原始论文在 spinroot 的 P10.pdf,官方文档是 JPL 的 C 编码标准。

    ranko查看英文原文

    The original paper describing and justifying these rules in more detail is at http://spinroot.com/gerard/pdf/P10.pdf, and the official document is at http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf

    补充指出这是经典文章并补充原始论文及相关讨论链接

    这是一篇经典之作。可惜文章没提到原始论文,另外 HN 上还有关于将这套 NASA 编码标准应用于 JavaScript 的有趣讨论。

    vog查看英文原文

    This is an all-time classic. Too bad that the article doesn't mention the original paper: http://pixelscommander.com/wp-content/uploads/2014/12/P10.pdf Some interesting HN discussions around applying these NASA coding standards to JavaScript: https://news.ycombinator.com/item?id=8856226

    相关资源

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

    关注向阳乔木

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

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

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