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

    编程语言与软件工程2018cs.utexas.edu

    编程艺术简明导论(1971)

    A Short Introduction to the Art of Programming (1971)

    入门 · 约 45 分钟读完前置知识:基本编程概念

    读论文 HN 讨论
    296HN 得分
    41条评论

    导读

    这是 Dijkstra 1971 年的著名手稿 EWD316,一篇编程艺术导论。他强调程序员的任务不是生产代码行,而是设计正确、优雅的程序,并批评将编程能力等同于熟悉某种语言工具细节的观念。

    HN 关注点:HN 读者惊叹于这篇 1971 年的文章对当今编程行业的洞察力——从 LOC 衡量生产力到并行编程的难度,许多观点至今仍然适用。

    关键词 DijkstraEWD316编程哲学并行计算

    HN 评论精选

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

    补充Dijkstra 在 1971 年就预见了并行计算的挑战,并指出并行编程比顺序编程难一个数量级

    1971 年就有如此深刻的见解:随着大规模集成(LSI)的出现,技术上可行去构建类似“算术单元云”的机器,信息处理活动在各处同时进行,甚至在短时间内彼此独立。为这样的机器编程将带来完全不同的权衡问题:人们愿意在实际用途尚未确立之前就投资于潜在有用的计算活动,以加速整个计算。但他不打算讨论这些问题,原因有二:其一,他怀疑这种并行形式在通用应用中能否被有效利用;其二,也是最重要的——并行编程比顺序编程难一个数量级。另外,这是“cloud”一词的首次出现,虽然含义不同。

    scscsc查看英文原文

    Quite an insightful thought for 1971: "With the advent of what is called "large scale integration" (being a term from the computer field, its acronym LSI is better known!) it seems to become technically feasible to build machines more like "clouds of arithmetic units" with information processing activities going on simultaneously all over the place, for shorter periods of time even independently of each other. Programming for such machines will pose completely different trade-off problems: one will be willing to invest in potentially useful computing activity before its actual usefulness has been established, all for the sake of speeding up the whole computation. But although I know such machines may be coming, I shall not touch these problems for the following reasons. First, as far as general purpose applications are concerned, I have my doubts about the effectiveness with which such forms of parallelism can ever be exploited. Second —and that is the most important consideration— parallel programming is an order of magnitude more difficult than sequential programming." Also, the first mention of "cloud", although with a different meaning.

    支持Dijkstra 早在 1971 年就批评用代码行数衡量生产力,但 47 年后这种做法依然普遍

    读到 1971 年写下的这段话令人大开眼界:把程序员的任务视为生产程序是不寻常的(虽然是个错误)。人们会发现诸如“软件制造”之类的术语,以及用每月产出的代码行数来衡量程序员生产率的提议——尽管我从未见过有人建议用作曲家每月在乐谱上涂写的音符数量来衡量其生产率!47 年后,很多人仍然用代码行数衡量编程生产力。更糟的是,一些主要自由职业平台甚至通过截取桌面截图或摄像头来追踪你的每一计费秒,‘以确保你在工作’。

    nickjj查看英文原文

    It's really eye opening to read something like, knowing it was written in 1971: > It is not unusual —although a mistake— to consider the programmer's task to be the production of programs. (One finds terms such as "software manufacturing", proposals to measure programmer productivity by the number of lines of code produced per month etc., although I have never seen the suggestion to measure composer productivity by the number of notes, monthly scribbled on his score!). 47 years later, a lot of people still measure programming productivity by LOCs. Hell, even major freelance marketplaces try to track your every billed second by taking screenshots of your desktop or webcam "just to make sure you're working".

    补充提供了该手稿的纯文本转录版本链接

    对于偏好纯文本版本的读者,可以从这个链接开始阅读。

    sohkamyung查看英文原文

    For those who prefer a plain text version, start reading from [1] [1] http://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD316.html

    质疑质疑 1971 年编程书籍已饱和的说法,但认同批评程序员能力被等同于掌握语言怪癖的观点至今有效

    对“市场已经充斥着太多计算机和编程入门读物”的说法表示怀疑——1971 年真的如此吗?但另一段话至今仍然成立:那些把程序员的能力等同于彻底掌握一种或多种现代编程语言和系统所退化成的巴洛克式工具的怪癖的人。

    coldtea查看英文原文

    >The market is already so heavily overloaded with introductory texts on computers and computer programming that one must have rather specific reasons to justify the investment of one's time and energy in the writing of yet another "Short Introduction to the Art of Programming". In 1971? I seriously doubt that... >[people] who identify the programmer's competence with a thorough knowledge of the idiosyncrasies of one or more of the baroque tools into which modern programming languages and systems have degenerated This, however, is as valid as ever...

    历次讨论

    同领域还值得读

    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

    关注向阳乔木

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

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

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