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 生成,可能有误。

    编程与软件工程gigamonkeys.com

    代码不是文学

    Code is not Literature

    3次上首页
    5年跨度
    438累计得分
    170条评论

    2014 — 2019,它一次次回到首页

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

    导读

    Peter Seibel(gigamonkeys 博主)在《Code is not Literature》中提出:代码不像小说那样适合“通读”,程序员很少会纯粹为了消遣去读代码;读代码更像做研究,需要带着问题、反复钻研才能理解。文章探讨了“读代码”这件事的真实形态,以及它与文学阅读的本质差异。

    为什么经久不衰:它挑战了“代码应像文学作品一样被阅读”的流行说法,给出了更贴近实际的读码方法论,多年来反复登上 HN 首页,至今仍是讨论代码可读性时的经典参照。

    关键词 代码阅读代码可读性学习方法编程文化

    HN 评论精选

    读代码必须带着问题和目的,否则这个比较本身就不成立

    问别人是否“纯粹为了乐趣”读过代码,这个问题本身就问错了——代码不是线性的,没有目的地读会非常吃力。但一旦带着目的(比如想弄懂或修复某个问题),熟练的读者就能快速找到有意义的线索。所以“没人真正读代码”是个稻草人:程序员其实一直在读代码,而且读得越多越擅长。

    ef4查看英文原文

    Asking people what they've read "just for the heck of it" is the wrong question, because code is not linear, so it's extremely ungainly to read without purpose. But as soon as the skilled code reader has a purpose in mind -- a question to answer -- he or she can rapidly find a meaningful narrative. Put into that context, programmers read code constantly, and the more they read the better they get. So I don't like the "nobody actually reads code" claim. It's a strawman. When I tell people to read code, it's always in the context of "pick something you want to understand or fix, and read with that purpose in mind." Not "the Linux kernel is like Moby Dick, you should really read it all."

    很多严肃文学也非线性,代码更接近这类需要研读的文本

    作者对“文学”的定义有些狭隘,不过他最终得出的结论是对的:代码需要“研读”而非“浏览”。代码确实不如通俗小说线性,但诗歌、哲学论著、史学分析和数学教材同样需要备着参考资料、反复前后翻阅地细读。

    jacobolus查看英文原文

    I think the author has a somewhat limited definition of “literature”, though he ultimately comes to the right conclusion that code must be “studied”, not “read”. It’s true, code is typically less linear than a pulp novel, but other types of literature are also involved, with layered meanings, which must be examined carefully, with reference material handy, and lots of flipping back and forth between sections. For instance, poems, philosophical treatises, historical analyses, and math textbooks must all typically be read this way.

    读代码的正确类比是学术研究式的反复精读,而非休闲阅读

    我很喜欢这篇文章,但不同意它的标题。从作者的经历和 Knuth 的例子看,读代码最好的方式是反复通读,直到能重新实现它或写出完整文档。这更像为文学作品写学术导读:学者会把一本书完整读三遍以上,在关键段落上花数小时、做大量笔记,彻底理解后才能清晰地阐述它——正如彻底消化的软件可以基于阅读中形成的思维模型被重写出来。

    bgilroy26查看英文原文

    >It was just basically the way you solve some kind of an unknown puzzle—make tables and charts and get a little more information here and make a hypothesis. In general when I’m reading a technical paper, it’s the same challenge. I’m trying to get into the author’s mind, trying to figure out what the concept is. The more you learn to read other people’s stuff, the more able you are to invent your own in the future, it seems to me. I really enjoyed reading this article, but I would argue with its headline. Based on the author's experience and the example from Donald Knuth, it seems like the best way to read code is to go through it multiple times to the point where you could reimplement it or provide complete documentation for it. The literary analog for code reading might be a writing a scholarly reader's companion to a book. You can't write a secondary source for a work of literature by reading it once through like a drugstore thriller or romance. A literary analyst would read the book through completely >3 times and spend hours on certain key passages. They would take extensive notes reconstructing the innerworkings of the characters, the relationships between them, and key themes. Once the work has been comprehensively understood, the scholar can write out in an expository manner what is going on in the piece of literature, the same way that a thoroughly digested piece of software can be rewritten based on the mental model that develops as you read. Obviously software and novels do not map completely one onto the other. I think the key similarity is that they both can be created with sufficient complexity to require taking multiple passes and following along with the author, building something similar yourself in order to truly understand them.

    读代码更像做实验:跑起来、改一改,而不是线性阅读

    Seibel 说读代码不像读文学而更像做科学,这个观察非常准确。面对分散在众多封装函数中的一万行代码,我的读法与读散文完全不同:文学可以线性地读,而代码必须追踪多条分支进入不同的逻辑流。我通过实验来学习代码——打开调试器单步执行、观察变量变化,更多时候是克隆 GitHub 上的项目去改、去扩展。我不建议只是打开代码库干读,要主动地折腾它、弄坏它、改进它。

    ideonexus查看英文原文

    Seibel's observation that reading code is less like literature and more like science is dead on. No matter how readable the code is, when I'm confronted with 10,000 lines of it spread across numerous encapsulated functions, I must tackle it very differently from how I read prose. With a complex literary text, I can just read it in linear fashion with occasional segueing to look up words and concepts, with well-engineered code I must follow numerous cases into different flows of logic. These aren't the same at all. I appreciate that he's trying to dispel the idea that we "read" code as we read for pleasure, I learn from code by experimenting with it. I open up the debugger and step through it, watch the variables change and see where it goes when I execute it. Most of all, I learn by changing that code and trying to build on it. I have enhanced my javascript skills immensely in recent years by cloning various projects on github and trying to expand on them or adopt them to my own purposes. I don't recommend opening up a code base and just reading it, actively engage it, break it, and enhance it.

    历次讨论

    同类还值得读

    1. 开源应用架构

      The Architecture of Open Source Applications

      《开源软件架构》(AOSA)是一本在线免费书,邀请知名开源项目的作者亲自剖析其内部设计,涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。

      编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选
    2. 编程语言简史:简短、不完整且多半错误

      A Brief, Incomplete, and Mostly Wrong History of Programming Languages

      一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章,用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。

      编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.com
    3. SQLite 是如何测试的

      How SQLite is tested

      SQLite 官方文档页,系统介绍 SQLite 的测试体系:多种测试方法(TCL 测试、模糊测试、回归测试、静态分析等)和海量测试用例,展示了这个小型开源项目如何靠极致测试获得…

      编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选
    4. 高级编程语言(2009)

      Advanced programming languages (2009)

      Matt Might 的经典文章,按用途推荐“高级编程语言”:如果追求就业就选主流语言,如果追求表达力、学术研究或创业,则推荐 Haskell、OCaml、Scala 等函数式语…

      编程与软件工程上首页 8 次 · 2009–2022matt.might.net
    5. 我的 Forth 与栈机器经历

      Yosefk - My history with Forth & stack machines

      作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程:既赞叹其简洁优雅、代码量小、可自举的优点,也坦率指出栈操作在实际编程中的痛苦,以及 Forth 社区文化中的问题。

      编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选

    打赏支持

    打赏二维码

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

    WeChat

    关注向阳乔木

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

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

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