Hacker News: 精华部分 (2016)

# HN：被低估的评论区 来源：http://danluu.com/hn-comments/ HN (https://twitter.com/danluu/status/1433297087362486272) 评论区 (https://twitter.com/altluu/status/1449285906360266754) 简直 (https://twitter.com/altluu/status/1452707802921652224) 糟糕透顶 (https://twitter.com/danluu/status/1584260625920032768)。对于 (https://twitter.com/altluu/status/1586623057019699200) 我了解的 (https://twitter.com/danluu/status/1346392037365436418) 任何 (https://twitter.com/danluu/status/1280651255275110400) 话题 (https://twitter.com/danluu/status/1498343295545581568)，绝大多数 (https://twitter.com/danluu/status/1512835522002972680) 评论 (https://twitter.com/danluu/status/1298477505272147968) 显然 (https://twitter.com/danluu/status/1277222715456282625) 都是错误的 (https://twitter.com/danluu/status/872676217350172673)。大多数情况下，没有任何相关领域的专业人士发表评论，而排在最前面的评论听起来貌似合理，实则完全错误。此外，许多评论还毫无必要地尖酸刻薄。你常常会听到类似这样的说法为刻薄的评论辩护：“这总比另一种情况好，大家只会在评论里互相吹捧‘这太棒了’”，仿佛当个混蛋就能成为抵御空洞陈词滥调的护身符。我曾见过有人对此提出异议；当被追问时，人们常说不刻薄就根本没法教别人东西，或者效率太低，好像骂别人蠢反而能帮助他们学习似的。就好像他们是从西蒙·考威尔那里学会了如何讲解事情，无法理解没有人身攻击的解释是什么概念。Paul Graham 曾说过：“哦，你永远不该阅读 Hacker News 上关于你写的任何东西的评论 (https://news.ycombinator.com/item?id=5937839)”。关于 HN 评论的大多数负面评价都是真的。然而，我至今没发现有哪个公开的互联网论坛能提供更好的技术评论。在我熟悉的领域，虽然一个讨论串里甚至找不到一条见多识广的评论是常态，但一旦这样的评论出现，它们通常会浮到最前面。在其他论坛，见多识广的评论要么不存在，要么即使出现，也会被那些听起来合理但完全错误的评论埋没，而且它们出现的频率比在 HN 上更低。就数量而言，评论区里有意思的“技术帖”可能比链接本身还多。嗯，这取决于你觉得什么有意思，但对我感兴趣的话题确实如此。如果我看到 nkurz 发表关于底层优化的评论，patio11 评论商业相关话题，nostrademons 评论公司运作方式，我几乎可以肯定我会读到一条有意思的评论。我能想到大约 20 到 30 位这样的人，他们不常写博客，但在 HN 上发表精彩的评论，而我怀疑我甚至没听说过的、在 HN 上发表精彩评论的人可能还不止这个数的一半1 (http://danluu.com/hn-comments/#fn:B)。我整理了一份非常简短的我喜欢的评论清单，因为评论似乎很容易被淹没。如果你写了一篇博客文章，多年后还会有人提及它，但评论大多会消失。我觉得这很可惜——HN 上有很多很棒的材料（当然，没那么棒的更多）。 #### MS Word 的文件格式是怎么回事 (https://news.ycombinator.com/item?id=12472505)？ > 基本上，Word 文件格式就是内存的二进制转储。我没开玩笑。他们就是把内存里的东西原封不动地写到磁盘上。我们可以试着推测原因（也许这样更快，也许让代码更小），但我认为最主要的原因是最初的开发者不懂其他更好的方法。后来当他们试图添加功能时，不得不努力保持向后兼容。这就是许多复杂性所在。有大量疯狂的变通方法来处理一些本可以通过重新设计文件格式来轻松解决的问题。这显然是管理层强制要求的，因为没有哪个软件开发者会无缘无故让自己承受那种折磨。后来他们添加了快速保存功能（我忘了它到底叫什么）。这种功能会将更改附加到文件中而不修改原始文件。他们实现这一点的方式非常巧妙，但极大地复杂化了文件结构。我必须指出一点（我记得在那篇文章最初发布时在 slashdot 上发了一大段评论），即文字处理软件的双向文件转换几乎是不可能的。因为文件格式没有包含足够的信息来格式化文档。最明显的例子就是分页。文件格式不会说明在哪里对文本流进行分页（除非用户明确输入）。它依赖于格式化程序来完成。每个文字处理软件格式化文本的方式完全不同。例如，Word 著名地错误分页脚注。但他们无法更改，因为这会破坏向后兼容性。这就是 Word Perfect 至今还能存活的唯一原因之一——它是唯一一种按照美国司法部要求对法律文件进行分页的文字处理软件。仅仅考虑分页问题，你就能看出问题所在。阅读 Word 文档时，你必须像 Word 一样进行分页——但文件格式并没有告诉你那是怎样的。然后如果有人修改了文档，你需要重新保存它，你需要用某种方式标记它应该像 Word 一样分页（即使它现在可能具有 Word 中没有的功能）。如果仅仅是分页问题，也许还能解决，但几乎每件事都是这样的。我推荐感兴趣的人阅读（一部分）XML Word 文件格式。你会看到大量标志，比如“像 Word 95 一样格式化”。这个格式没说那是什么——因为很明显，文件格式的作者们自己也不知道。这迷失在一团糟的遗留代码中，没人能搞清楚它现在到底做什么。 #### NULL 的乐趣 (https://news.ycombinator.com/item?id=12007286) > 这是另一个关于这个精妙特性的例子： ```c #include <stdio.h> #include <stdlib.h> #include <string.h> #define LENGTH 128 int main(int argc, char **argv) { char *string = NULL; int length = 0; if (argc > 1) { string = argv[1]; length = strlen(string); if (length >= LENGTH) exit(1); } char buffer[LENGTH]; memcpy(buffer, string, length); buffer[length] = 0; if (string == NULL) { printf("String is null, so cancel the launch.\n"); } else { printf("String is not null, so launch the missiles!\n"); } printf("string: %s\n", string); // 对 null 未定义，但实际中可能有效 #if SEGFAULT_ON_NULL printf("%s\n", string); // 当裸用 "%s\n" 时在 null 上会段错误 #endif return 0; } nate@skylake:~/src$ clang-3.8 -Wall -O3 null_check.c -o null_check nate@skylake:~/src$ null_check String is null, so cancel the launch. string: (null) nate@skylake:~/src$ icc-17 -Wall -O3 null_check.c -o null_check nate@skylake:~/src$ null_check String is null, so cancel the launch. string: (null) nate@skylake:~/src$ gcc-5 -Wall -O3 null_check.c -o null_check nate@skylake:~/src$ null_check String is not null, so launch the missiles! string: (null) ``` > 看起来 Intel 的 ICC 和 Clang 还没能跟上 GCC 的优化步伐。如果你依赖这个优化来获得所需性能，那就糟了！但在过分批评 GCC 之前，请考虑一下，当 string 为 NULL 时，所有这三个编译器在执行 `printf("string: "); printf("%s\n", string)` 时都会段错误，而将 `printf("string: %s\n", string)` 作为单条语句执行却毫无问题。你能看出为什么使用两条独立的语句会导致段错误吗？如果不能，这里有个提示：https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25609 #### 如何确保自动驾驶备份系统保持专注 (https://news.ycombinator.com/item?id=11017034)？ > 良好的工程设计会尽可能消除用户做错事的可能性。...你不会设计一个容易被误用的功能，然后试图用说明来防止这种误用。澳大利亚曾发生过一起名为“瀑布事故”的脱轨事件 [1]。事故原因是司机心脏病发作，导致 7 人死亡（说真的，死亡人数这么低简直是奇迹）。根本原因是无人警惕开关（dead-man's switch）的失效。在瀑布事故案例中，司机有两个可用的无人警惕开关——1) 油门手柄需要克服弹簧力保持在小角度旋转；或 2) 可以踩下地板上的一个踏板。你必须做其中一件事，设计初衷是让司机通过交替使用两者来防止手腕或脚抽筋。如果两者都未操作，就会触发紧急制动。结果发现这位司机太胖了，以至于心脏病发作时，他的腿还能将踏板踩下足够程度来保持紧急系统不动作。因此，当驾驶座上躺着一个“死人”时，无人警惕系统从未触发。我不太记得瀑布事故中系统的具体细节，但对抗这种情况的一种方法是要求踏板保持在释放和完全踩下之间的中间位置。设计思路是，一条“死腿”会将踏板完全踩下从而触发刹车，而完全释放踏板也会触发刹车。我不知道他们是否有这样的系统，但这肯定是铁路行业使用的一种方法。无论如何，同样的问题在汽车上也可能发生。如果你失去意识并且腿脚瘫软，根据腿相对于踏板的位置和在地板上的杠杆作用，足够重的腿可能会稍微踩住踏板。我熟悉的另一个确保司机在岗时保持清醒的主要系统叫做“警惕性（vigilance）”。其工作方式是，仪表盘上的灯会定期闪烁，司机必须确认。如果他们没有确认，蜂鸣警报会响起。如果他们仍然没有确认，火车制动器会启动，并假定司机丧失能力。让我告诉你一些我参与相关工作的经历。我们刚开始时，有一个简单的警惕系统。每隔大约 30 秒（例如），司机需要按一个按钮。好的，没问题。但后来司机们变得如此习惯于每 30 秒按一次按钮，以至于出现司机打瞌睡/睡着后，仍然能精确地每 30 秒按一次按钮的情况，因为这已深入骨髓，简直成了下意识动作。于是我们引入了随机时间警惕系统，时间在 30-60 秒（例如）之间变化，而且你只能在灯开始闪烁后的一个小时间段内确认。再次，司机们开始打瞌睡/半睡半醒，每次警报一响他们就会立刻按下。于是我们引入了随机时间、任务关联的警惕系统，这终于解决了这个问题。现在，司机必须按下按钮、转动旋钮或执行一系列不同的活动，而且他们必须在随机选择的时间内完成那个随机选择的活动，以此来确认他们的清醒状态。直到那时，我们才最终解决了司机警觉性的问题。另见 (https://news.ycombinator.com/item?id=12013713)。 #### 声望 (Prestige) (https://news.ycombinator.com/item?id=11833832) > 好奇他为什么需要搬到一个更有声望的职位？大多数人在 30 多岁时都会意识到，声望是一场愚者的游戏；这是一种通过用他们并不真正在乎的人的赞誉来诱导人们去做那些没什么乐趣、他们自己本来并不想做的事情的方式。 #### 为什么 FedEx 总部设在孟菲斯 (https://news.ycombinator.com/item?id=9282104)？ > ...我们注意到还需要：(1) 枢纽地点有一个合适的现有机场。(2) 枢纽地点天气良好，例如，雪、雾或雨相对较少。(3) 能够方便使用优质的停机坪空间，即用于停放、维护飞机和分拣包裹的地方。(4) 良好的劳动力供应，例如用于分拣中心。(5) 相对较低的生活成本以保持价格低廉。(6) 友好的监管环境。(7) 候选机场不要太繁忙，例如，不希望到达的飞机需要盘旋很长时间才能降落。(8) 机场侧风相对较少，并且有多条跑道可供选择，以防大风。(9) 跑道海拔不要太高，例如，不要高到限制最大总起飞重量，例如，排除丹佛。(10) 跑道尽头附近没有高大障碍物，例如山脉。(11) 充足的航空燃油供应。(12) 方便 18 轮卡车通行的公路，以便在卡车和飞机之间交换包裹，例如，这样一部分货物可以通过卡车运到枢纽仓库存储，然后直接通过飞机运送给下单的客户，比如在晚上 11 点前下单，次日上午 10 点前送达。所以，大约有三个候选地点：孟菲斯，以及我回忆中的辛辛那提和堪萨斯城。孟菲斯机场跑道旁有一些二战时期旧机库可供 FedEx 用作分拣中心、飞机维修和总部办公空间。交易达成——就是孟菲斯了。 #### 为什么 Etherpad 加入了 Wave，以及为何结果不如预期 (https://news.ycombinator.com/item?id=2320172) > 决定出售给 Google 是我和我的联合创始人生中最艰难的决定之一。我们对 Wave 的愿景感到兴奋，尽管我们看到了产品的缺陷。Wave 团队告诉我们他们希望我们帮助让 Wave 更简单、更像 etherpad，我们想我们能帮上忙，尽管最终我们没能成功让 Wave 变简单。我们害怕 Google 成为竞争对手：他们拥有更多工程师和更多资金支持这个项目，而且他们运营它的方式更像一个独立的初创公司，而不是一个普通的大公司部门。Wave 办公室在澳大利亚，几乎拥有完全的自主权。最后，在 AppJet 濒临失败 1.5 年后，能够宣布我们的努力取得成功，并为我们所有拿钱冒险投资我们的投资者提供可观回报，是很有诱惑力的。最终，我们加入 Wave 的决定没有像我们希望的那样成功。最大的教训是，拥有更多工程师和资金支持一个项目实际上可能弊大于利，因此我们出于这个原因害怕 Wave 成为竞争对手是错误的。事后看来这似乎很明显，但当时并非如此。其次，我完全低估了在 Wave 代码库上进行迭代的难度。我习惯于在一次通宵工作中重写软件的大部分内容。由于 Wave 采用的软件开发流程，对产品进行迭代实际上是不可能的。我本应更深入地调查他们具体的软件工程流程，但我却因为他们看起来像初创公司一样运作，就假设他们也能像初创公司一样迭代。很多产品问题整个 Wave 团队都知道，但我们被一个庞大复杂的代码库、糟糕的技术选择以及阻碍快速迭代的繁琐工程流程所拖累。 #### 科技新闻的准确性 (https://news.ycombinator.com/item?id=12345365) > 当我掌握某个后来在科技媒体上爆出的新闻的内部消息时，我总是震惊于它的报道与实际情况有多么不同...