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

    编程语言与软件工程2016arxiv.org

    科学计算中的“足够好”实践

    Good Enough Practices in Scientific Computing

    入门 · 约 25 分钟读完前置知识:版本控制(Git)基础、命令行与脚本编程、科研数据分析流程

    读论文 HN 讨论
    143HN 得分
    20条评论
    1次被评论区引用

    导读

    这篇论文提出科研计算中一套"够用就好"的实践清单,涵盖数据管理、代码组织、版本控制、文档与引用等方面,目标是让研究可复现、可交接。它不追求软件工程的最佳实践,而是给出科研人员容易落地的最低标准。

    HN 关注点:这类规范虽有道理,但科研环境中缺乏执行激励,讨论焦点落在如何让研究者真正愿意遵守。

    关键词 scientific computingreproducibilityresearch softwareopen science

    后来怎么样

    它成为科研软件与可复现性培训中被广泛采用的入门规范之一,常与 Software Carpentry 教学、期刊的代码与数据可用性政策一并引用,把“最低可复现标准”从口号变成了可对照的清单。

    HN 评论精选

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

    补充建议补上 Makefile,或者不带参数即可运行的总控脚本,作为分析可复现的清单。

    论文有意没有提到 Makefile 这一条。我自己会把“有一份 Makefile”也算进“够用就好”的实践里。具体用 Makefile 还是别的总控脚本或工具都无所谓,关键是你要有一份清单式文件,说明每个派生数据文件是怎么生成的,并且能在不带参数的情况下直接运行,从原始数据一路跑完整套分析。这在我过去多次帮上了忙。

    mbreese查看英文原文

    One thing they (intentionally) left out was including a Makefile. This is one of the "Good Enough" practices that I also include. It doesn't matter if it is a Makefile or another master script or tool. What is important is that you have a manifest for how each derived data file was generated. And it should be able to be executed w/o arguments to have the entire analysis run from the raw/primary data. This has saved me many times in the past.

    质疑缺乏奖惩机制,规范讲了也没用;除非像实验规程那样强制化,否则人的习惯不会改变。

    我在一个大型开源科学项目中工作过,这篇论文读起来非常像我们给每位新学生和博士后讲的那套话。但结果几乎是两极分化:要么他们既明白该做什么、为什么重要,而且本来就这么做了;要么既不明白也从不这么做。这些年我几乎没见过有人从一个阵营跳到另一个阵营。原因在于,遵守良好的计算实践很少带来可见收益。前人手上一堆残缺、难读的代码,确实会给接手的人带来巨大痛苦,最后基本只能从头重写(我就是这样的人),但把烂摊子传下去没有任何惩罚,清理代码和数据也极少有奖励。那何必费这个劲?和开源出版之争一样,必须先有激励机制,人们才会去做。生物实验规程、光伏性能数据报告都有标准化并且强制的做法,计算领域只有出现类似机制,我才会看到改善。

    suchsciencewow查看英文原文

    Having worked with a large open-source scientific project, this is extremely reminiscent of the type of talk we would give to every new student or post-doc joining the project. Unfortunately, the outcome is entirely binary - either they understand both what to do and why its important, and also happen to do it already, or they don't understand it and they don't already do it. I can't really think of a single person who jumped from one category to the other over the years. The reason for that is there was rarely any visible benefit from putting in the work to follow good computing practices. It certainly created a lot of pain when jumbles of broken and unreadable code were passed on to new people, who basically ended up reimplementing everything from scratch (I was one such person), but there is exactly zero punishment for doing that, and very rarely any reward for cleaning up code and data. So why bother? As with the open-source publishing debate, there has to be an incentive system in place, and then people will do it. There are standardized (and required!) practices for things like bio protocols or reporting PV-performance data - only if computing had something similar do I see anything improving.

    支持CITATION 文件解决了软件难以被学术引用的长期痛点。

    看起来挺合理。我感兴趣的一点是 CITATION 文件。写作时用到某款软件却无法引用它,是个反复出现的麻烦。

    dibanez查看英文原文

    Seems reasonable. An interesting bit for me was the CITATION file. The lack of citability for software is a recurring annoyance when writing up work that uses that software.

    补充提议对 HN 上分享的研究做一次合规性自查式讨论。

    我希望大家持续讨论 HN 上贴出的研究在多大程度上符合“够用就好”的标准。

    RA_Fisher查看英文原文

    I'd like to see ongoing discussion of the extent that HN-posted research conforms to being "Good Enough."

    相关资源

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

    关注向阳乔木

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

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

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