HackerURLs

一次又一次被重新发现的经典。

同一个链接,相隔一年以上,一次又一次被人重新发现、再次冲上 Hacker News 首页。能经受住这种时间检验的,大多是值得一读再读的文章。每篇附中文标题,讨论最热的那些再加上中文导读和高赞评论翻译。

从名人堂开始
  • 4,700+篇经过时间检验的经典

Hall of fame

名人堂

在经典库里看全部精选

上首页次数最多、而且有中文导读的 30 篇。时间轴上每个黑点是一次上首页,空心点是一次没冲上去的投稿。

  1. 正在载入经典…

Archive

经典库

按第一次上首页的年份分布,点柱子筛选。

排序

    About

    这些经典是怎么挑出来的

    1. 01

      合并同一个链接

      读取 Hacker News 自 2006 年以来的全部链接投稿,把 http/https、www、跟踪参数等写法不同的同一篇文章合并成一条。

    2. 02

      只留经得起时间的

      同一链接至少两次拿到 50 分以上(约等于上首页),而且两次相隔一年以上;再由 AI 剔除状态页、产品首页和新闻事件。

    3. 03

      写导读、译评论

      上首页次数最多的 2,000 篇配上中文导读、"为什么经久不衰",并精选翻译 HN 高赞评论。导读由 AI 生成,可能有误。

    算法与计算机科学cs.utexas.edu编辑精选

    Dijkstra:论真正教授计算科学的残酷性(1988)

    On the cruelty of really teaching computing science (1988)

    3次上首页
    12年跨度
    310累计得分
    190条评论

    2012 — 2024,它一次次回到首页

    黑点是上首页(≥ 50 分)的那次投稿,空心点是没冲上去的投稿,点越大分数越高。

    导读

    这是 Dijkstra 1988 年的著名讲稿《论真正教授计算科学的残酷之处》,主张编程教学应抛弃'凭直觉摸索'的方式,转向基于数学和形式化方法的严谨思维,并批评把计算机拟人化、用操作语义思考程序的坏习惯。文中还包含他对编程教育、正确性证明等问题的尖锐观点。

    为什么经久不衰:它提出的'程序员该不该学数学化思维、形式化方法是否现实'之争至今没有定论,三十多年后仍是编程教育与方法论讨论的核心参照。

    关键词 Dijkstra编程教育形式化方法程序正确性

    HN 评论精选

    形式化方法在实践产出上完全落败,Dijkstra 的主张缺乏实际软件的支撑。

    这篇演讲实质上是要抛弃一种催生了计算史上几乎所有实用软件的编程开发方式,转而支持一种到 1988 年为止没产出过任何非平凡软件、此后二十多年也没有的方法。我欢迎有人为 Dijkstra 的观点辩护,但那样的论证若能引用真正用端到端形式化方法开发的、可运行的完整程序(而非孤立算法),会更有说服力。

    microtherion查看英文原文

    What this talk essentially proposes is to scrap the teaching of an approach to program development that has produced pretty much EVERY SINGLE piece of practical software used in the history of computing, in favor of an approach that had not produced, to my knowledge, a single nontrivial piece of software by 1988, when the talk was given, and has not produced, to my knowledge, a single piece of software in the 20+ years since. In a separate thread, I have posted De Millo, Lipton, and Perlis' 1979 argument against formal methods: http://fresh.homeunix.net/~luke/misc/p271-de_millo.pdf and 30+ years after that article, and 20+ years after Dijkstra's talk, I don't see how there can be an argument as to which of the two views has prevailed in practice. I would welcome hearing Dijkstra's view argued, but I would find such an argument much more compelling if it included citations of actual, working programs (as opposed to isolated algorithms) that were developed with end-to-end formal methods. It would be even more compelling if the argument included published proofs of such programs and/or the author's personal experience developing them.

    业余程序员和'不完美'软件创造了巨大价值,证明 Dijkstra 的精英主义路线是错的。

    Dijkstra 在'不会写正确程序的人该不该编程'这个问题上站错了边。我们用'不正确的程序'建起了庞大、繁荣且相当可靠的信息基础设施。想象一下:如果只有受过严格数学与形式方法训练的人才能写代码,就不会有会计做的 Excel 表格、自定义的 HTML/CSS,甚至 wiki 标记语言——那将是一个多么贫瘠的世界。

    dkarl查看英文原文

    Dijkstra is one of my favorite writers on programming, but I can't resist pointing out that he was on the wrong side of "how to program if you cannot." We have a huge, thriving, valuable, and quite reliable information infrastructure built out of incorrect programs. Dijkstra believed in correct programs and believed that software engineering would not succeed without them. He believed it was counterproductive to teach people to program and employ them as programmers if they could not write correct programs. He believed that the future of computing would be defined by the struggle to write correct programs, and that even if we managed to get by with incorrect programs, the cost would be much greater than if we had achieved the same results via correct programs. Wow! Can you imagine where we would be if we only had code written by people who had completed rigorous training in mathematics and formal methods? Can you imagine a world where the middle ground between mathematics and the analog world was completely bare? No Excel spreadsheets made by accountants, no customized HTML or CSS, no wiki markup even, because you can't trust amateurs to do programming! It's hard to wrap my head around the idea that The Print Shop for the Apple II should never have existed, because the small minority of people suited for Dijkstra's rigorous training in mathematical programming would surely have been engaged on far more important projects. Hmm, the essay is dated 1988. I wonder if he still believed that a small class of elite programmers armed with formal methods would have created all of the wonderful programs I used at school around that time -- Print Shop, Where in the World is Carmen Sandiego?, Math Blaster, and on and on -- did he believe his mathematician/programmers would have created all those programs and even more? Or was he simply out of touch? Ah, but how wonderfully and brilliantly out of touch. He is also wrong about software aging and needing maintenance, as well, but there is an important lesson to learn from what he said. As usual, he is right about the mistake in language even though he is wrong about the phenomenon it refers to: programs are routinely transplanted from one context to another, because it is expensive or inconvenient to maintain their original context. Aging and maintenance are a poor analogy. Using poor language to address something is, in practice, less wrong than simply ignoring it, but we would be better off if we heeded Dijkstra's advice not to lean on bad analogies for novel situations.

    Dijkstra 对操作式思维的批评切中要害,纯函数式思维本可避免大量复杂性和错误。

    关于拟人化思维'使人们无法摆脱操作语义、被迫基于计算模型去思考程序行为,是巨大的脑力浪费'——我每天在工作中都看到这种后果。大多数程序员完全没有意识到大部分计算是无时间的:纯函数、静态的,就像老式数学一样。他们却不断引入时间、变化及其带来的复杂性和错误,只因没人教过他们更好的思考方式。

    loup-vaillant查看英文原文

    > [Anthropomorphism] is paralyzing in the sense that, because persons exist and act in time, its adoption effectively prevents a departure from operational semantics and thus forces people to think about programs in terms of computational behaviours, based on an underlying computational model. This is bad, because operational reasoning is a tremendous waste of mental effort. I see the effects of this every day at work. And the resulting programs are indeed much complicated by needless uses of procedural style. It appears most programmers are completely oblivious to the fact that most computation is completely timeless. It's pure functions. It's static. Just like good old fashioned Math™. Nevertheless, they go on introducing time, change, and all the complexities and errors that goes with them, just because nobody taught them to think any better. It is quite infuriating that I am sometimes forced to follow that trend, sometimes because otherwise my colleagues wouldn't understand my code, but more often because the APIs they wrote are based on mutation when there was no need, or their functions aren't total even though they could have been.

    历次讨论

    同类还值得读

    1. 位运算技巧集

      Bit Twiddling Hacks

      斯坦福页面上的经典位运算技巧合集,收录了 popcount、前导/尾随零、位反转、交换、舍入等大量技巧,并附有解释和性能讨论。

      算法与计算机科学上首页 8 次 · 2011–2024graphics.stanford.edu编辑精选
    2. 如何不按平均评分排序

      How Not To Sort By Average Rating

      经典文章解释了为什么按平均评分排序不可靠:只有少量评价的条目(比如仅一条五星)会轻易排到最前,而评价数量的差异被忽略。

      算法与计算机科学上首页 7 次 · 2009–2024evanmiller.org编辑精选
    3. 数据结构可视化

      Data Structure Visualizations

      旧金山大学 David Galles 教授制作的数据结构与算法交互式可视化网站,涵盖 B 树、红黑树、排序、图算法等,可逐步操作观察其运行过程。

      算法与计算机科学上首页 6 次 · 2011–2021cs.usfca.edu编辑精选
    4. 1996 年以来的计算机科学最佳论文奖

      Best Paper Awards in Computer Science since 1996

      Jeff Huang 维护的一个汇总页面,收录了自 1996 年以来计算机科学各主要会议的“最佳论文奖”获奖名单,并按年份和会议整理,方便读者一站式浏览历届获奖论文。

      算法与计算机科学上首页 6 次 · 2010–2018jeffhuang.com编辑精选
    5. 算法(Jeff Erickson)

      Algorithms, by Jeff Erickson

      伊利诺伊大学 Jeff Erickson 教授的算法课教材,免费在线开放。

      算法与计算机科学上首页 5 次 · 2018–2022jeffe.cs.illinois.edu编辑精选

    打赏支持

    打赏二维码

    觉得有用,请作者喝杯咖啡。

    WeChat

    关注向阳乔木

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

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

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