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

    编程与软件工程ronaldduncan.wordpress.com

    ASCII 分隔文本——不是 CSV 或 TAB 分隔文本

    ASCII Delimited Text – Not CSV or TAB delimited text

    2次上首页
    10年跨度
    815累计得分
    398条评论

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

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

    导读

    这篇文章主张用 ASCII 控制字符(单元分隔符 US 0x1F、记录分隔符 RS 0x1E)作为文本数据的分隔符,而不是 CSV 或制表符,因为数据字段中可能包含逗号、引号或换行,导致解析出各种边界问题。这套方案早在上世纪 60 年代就已设计好,但至今未被主流工具广泛支持。

    为什么经久不衰:它揭示了一个经典矛盾:技术上更严谨的方案(ASCII 分隔符)因生态不支持而败给了有无数边界问题的 CSV/TSV,这种“正确但没人用”的工程困境至今仍有借鉴意义。

    关键词 数据格式CSVASCII文本解析

    HN 评论精选

    实践过的人反馈:编辑器和表格工具不支持,且手工输入困难,实际体验很差

    我试过这个方案,结果所有人都讨厌它。大多数文本编辑器无法正常显示这些字符(要么完全隐藏,要么显示一个无用的“未知”占位符),表格工具也不支持记录分隔符(虽然都允许自定义字段分隔符)。另外还有个明显问题:别人手工编辑文件时,根本没法方便地输入这些字符。

    Pxtl查看英文原文

    I've done this. Everybody hated it. Most text editors don't display anything useful with these characters (either hiding them altogether or showing a useless "uknown" placeholder), and spreadhseet tools don't support the record separator (although they all let you provide a custom entry separator so the "unit" separator can work). Besides the obvious problem that there's no easy way to type the darned things when somebody hand-edits the file.

    行业现实:TSV/CSV 已成事实标准,更优的方案也难以被采用

    别这么做。TSV 已经赢得了这场竞赛,CSV 紧随其后。任何其他方案都会给你和你的数据科学家、程序员同事带来无尽的痛苦。我以一个日常解析 20GB 文本文件(主要是 TSV,偶尔 CSV)为生的人的身份说这话。你提出的方案确实更优,但短期内不会被采用。

    dxbydt查看英文原文

    Don't do this. Tsv has won this race, closely followed by Csv. Anything else will cause untold grief for you and fellow data scientists and programmers. I say this as someone who routinely parses 20gb text files, mostly Tsv's and occasionally Csv's for a living. The solution you are proposing is definitely superior but isn't going to get adopted soon.

    CSV 的边界问题众多,而 ASCII 控制字符方案早已存在

    任何解析过任意数据的人都知道 CSV/TAB 格式在输入输出时那数不清的边界情况。然而就像虚拟内存和虚拟机一样,解决方案早在 60 年代就已存在。想了解 ASCII 表中那些奇怪字符的历史和用途,可以看这个链接。

    mikestew查看英文原文

    Anyone that's ever had to parse arbitrary data knows of the approximately 14 jiggityzillion corner cases involved when sucking in or outputting CSV/TAB delimited formats. Yet much like virtual memory and virtual machines, we find that a solution has existed since the 60s. For those wondering about the history and use of all those strange characters in your ASCII table: http://www.lammertbies.nl/comm/info/ascii-characters.html

    标准 Unix 工具链假设换行为记录分隔符,该方案破坏了文本格式的可读性优势

    可惜这方案和标准 Unix 工具不兼容,而那正是我处理制表符分隔文本的主要方式。字段分隔符可以随意改,几乎所有工具都支持参数化;但换行作为记录分隔符几乎是所有工具的默认假设(包括标准工具集和 Google 的 crush-tools)。Google 的默认是 0xfe 作字段分隔符、换行作记录分隔符。另外,用文本格式的优势之一就是能用标准文本查看器浏览,这点也被牺牲了。

    mjn查看英文原文

    Alas, I don't think this works with the standard Unix tools, which is the main way I process tab-delimited text. Changing the field delimiter to whatever you want is fine, since nearly everything takes that as a parameter. But newline as record separator is assumed by nearly everything (both in the standard set of tools, and in the very useful Google additions found in http://code.google.com/p/crush-tools/). Google's defaults are ASCII (or UTF-8) 0xfe for the field separator, and '\n' for the record separator. I guess that's a bit safer than tabs, but the kind of data I put in TSV really shouldn't have embedded tabs in a field... and I check to make sure it doesn't, because they're likely to cause unexpected problems down the line. Generally I want all my fields to be either numeric data, or UTF-8 strings without formatting characters. Not to mention that one of the advantages of using a text record format at all is that you can view it using standard text viewers.

    历次讨论

    同类还值得读

    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

    关注向阳乔木

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

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

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