2024 04 22 HackerNews

2024-04-22 Hacker News Top Stories #

一句话摘要 #

  1. Programming Is Mostly Thinking (2014) 文章《Programming Is Mostly Thinking》由 Tim Ottinger 撰写，强调编程主要是思考过程，而非仅仅是编码。
  2. Why you should not apply to YC Daniel Vassallo 在 Twitter 上发表的推文讨论了为何申请加入 Y Combinator（YC）孵化器项目可能是一个糟糕的主意。
  3. I bought 300 emoji domain names from Kazakhstan and built an email service (2021) “Mailoji” 项目讲述了作者购买哈萨克斯坦的 300 个表情符号域名并建立表情符号电子邮件服务的故事。
  4. Tiny World Map GitHub 仓库 “tinyworldmap” 提供了一个小型世界地图，专为离线优先和低带宽的 Web 应用设计。
  5. I made an open source Windows app to rewind and search everything on screen 开源应用程序帮助用户在 Windows 系统上回放并搜索屏幕上的一切，由个人出于兴趣开发。
  6. Two lifeforms merge in once-in-a-billion-years evolutionary event 文章介绍了科学家目睹的一次罕见的进化事件，两种生命形式合并成一个新的生物体，拥有独特的能力。
  7. Bringing Exchange Support to Thunderbird 文章介绍了 Thunderbird 将通过 Rust 语言实现对 Microsoft Exchange Web Services (EWS) 的原生支持。
  8. Racket Language Racket 编程语言的最新版本 8.12 发布，这是一种支持面向语言编程的成熟、实用且可扩展的语言。
  9. I love programming but I hate the programming industry 文章探讨了作者对编程的热爱与对编程行业的厌恶，批评了行业对代码产出的过度关注而忽视了问题解决的重要性。
  10. Doom-htop: The classic DOOM game over htop 开源项目 “doom-htop” 将经典游戏 DOOM 的图形嵌入到 htop 进程查看器中，通过共享内存和键盘记录器实现。

Programming Is Mostly Thinking (2014) #

http://agileotter.blogspot.com/2014/09/programming-is-mostly-thinking.html

这篇博文名为《Programming Is Mostly Thinking》，作者是 Tim Ottinger。文章讨论了编程实际上是大部分思考的过程。作者提到了一个假设：如果一天中你只需要参加几个会议，没有太多离题的对话，没有太多干扰或中断，不需要做大量的状态或时间报告，并且能够专注地进行六个小时的严肃编程，那将是一个非常棒的编程日。然后作者提出了一个问题：如果你失去了一整天的工作，但有一个变更（diff）文件，你需要多长时间才能将这六个小时的工作重新输入到代码库中？

文章中指出，编程其实是 11/12 的思考和 1/12 的实际操作。作者并没有通过科学研究得出这个数字，而是通过多年的非正式调查得出的结论。他强调了在软件开发中，大部分工作是思考而不是敲击键盘。作者还提到了软件工厂的概念，指出现代软件开发已经完全实现了工厂化生产，而程序员的主要工作是设计数据模型，以便后续工厂生产出符合需求的软件副本。

文章还探讨了编程过程中的思考和决策，强调了大部分工作是在决定如何进行变更，而不仅仅是实际的变更操作。作者指出，程序员在社会环境中工作，他们的成果都融入到共享的代码库中，这也需要与他人进行连接和沟通。最终，文章总结道，如果编程是 11/12 思考和 1/12 实际操作，那么我们应该提供必要的材料、环境和流程，以确保我们的思考质量高，而不是让人们大部分时间都在敲击键盘。

HN 评论 247 comments | 作者：ingve | 17 hours ago #

https://news.ycombinator.com/item?id=40103407

这篇帖子中的评论观点大致可以归纳为以下几点：

    1. 优秀的开发者在动手编码之前会花费 90% 或更多的时间进行思考，但大多数人无法在脑中同时保留大量约束和概念。
    1. 编程过程中的思考应该结合实际编码，通过实际编码来测试想法，只有这样才能真正理解想法对最终代码的影响。
    1. 设计过于复杂可能需要简化，保持简单有助于日后的维护。
    1. 在学习新语言或环境时，探索性编码是很常见的，有助于快速学习和理解。
    1. 编写代码应该被视为“思考过程”的一部分。
    1. 有时候，写代码是为了理解为什么不应该写代码。
    1. 编程是大多数时间的思考和一些时间的实际编码的结合，这种平衡适应于不同的使用情况。
    1. 编程是对世界事务进行认真思考的过程，代码只是对所建立理论的简单表达。

Why you should not apply to YC #

https://twitter.com/dvassallo/status/1781751108211511680

这条推特是由 Daniel Vassallo 发布的，内容主要是关于为什么你不应该申请加入 YC（Y Combinator）孵化器项目的理由。Daniel 指出，YC 看起来是一个合理的选择，他们会给你一些资金来帮助创业，并承诺提供一个可以帮助你前进的人群社区。但是，实际上，他认为这是一个糟糕的主意。他解释了一个重要概念——非遍历性（non-ergodicity），即在某些系统中，对于整体最有利的并不一定对组成该群体的个体最有利。在这种情况下，YC 会试图利用你，而你可能会失去利益。

Daniel 还通过比喻隐藏宝藏的搜索方式，说明了在非遍历性系统中的商业策略。他指出，YC 会告诉你，如果加入他们，你更有可能拥有一个价值十亿美元的企业，但实际上只有大约 1.25% 的公司达到了这一期望。此外，他还讨论了 YC 教授的一些错误观念，比如成功的公式和“转变”概念，并指出这些并不适用于现实世界的商业机会。

最后，Daniel 提到了他自己的社区，强调了与 YC 不同的经营理念，认为 YC 实际上也在向你推销东西。他警告说，要谨慎对待 YC 的承诺，因为成功的商业主通常是在 40 到 50 岁之间，而 YC 却充斥着 20 多岁的创业者。他强调了在商业中避免预测的重要性，并指出 YC 教导的东西往往是不适用于现实世界的，需要进行“反学习”。

HN 评论 188 comments | 作者：georgehill | 1 day ago #

https://news.ycombinator.com/item?id=40099585

这篇帖子中的评论观点主要包括：对 YC 的批评、关于 YC 的成功率、关于创始人的报酬、关于创业的风险、关于 YC 的服务和网络、关于创始人的控制权、关于 YC 的成功案例、关于创始人的报酬、关于 YC 的名声、关于创始人的风险容忍度

I bought 300 emoji domain names from Kazakhstan and built an email service (2021) #

https://tinyprojects.dev/projects/mailoji

这个项目名为"Mailoji"，讲述了作者购买了来自哈萨克斯坦的 300 个表情符号域名，并建立了一个表情符号电子邮件服务的故事。作者购买了一个邮箱表情符号域名 📪.ws，并尝试将其用于电子邮件地址，但由于表情符号域名易被认为是垃圾邮件而被拦截。

随后，作者购买了更多哈萨克斯坦的表情符号域名，建立了一个服务，允许用户注册任何表情符号的电子邮件地址。通过 TikTok 广告，作者成功售出了多个表情符号电子邮件地址，取得了一定的收入。最终，作者在 Product Hunt 上推出了 Mailoji，取得了一定的成功，售出了 150 多个表情符号电子邮件地址，年收入约为 830 美元。

虽然项目目前年收入约为 1440 美元，但作者认为创建表情符号电子邮件服务是一次有趣的冒险，展示了技术应该更有趣的观点。

HN 评论 87 comments | 作者：montyanderson | 24 hours ago #

https://news.ycombinator.com/item?id=40101885

评论中的观点归纳如下：

  • 对作者购买的 300 个表情符号域名和构建电子邮件服务的做法感到有趣和有趣。
  • 一些评论关注了评论者的用户数量和收入情况。
  • 有人提到了德国和哈萨克斯坦之间的域名问题。
  • 一些评论者讨论了表情符号在电子邮件地址中的使用和技术挑战。
  • 有人提到了域名的法律问题和所有权。
  • 一些评论者讨论了区块链技术在域名管理中的潜在应用。
  • 评论中还包括了关于域名所有权、电子邮件服务和技术挑战的观点。

Tiny World Map #

https://github.com/tinyworldmap/tiny-world-map

这个 GitHub 仓库（ https://github.com/tinyworldmap/tiny-world-map）包含了一个名为 tinyworldmap 的小型世界地图，旨在为离线优先和低带宽的 Web 应用提供支持。该地图设计用于与 Leaflet 一起使用，支持所有缩放级别，最完整的版本仅有 300KB（经过 gzip 压缩）。

默认情况下，地图显示了 OpenStreetMap 中添加的人口最多的 1 万个城市。除了作为基础地图替代 OpenStreetMap 瓦片外，还可作为 OpenStreetMap 瓦片的离线备用。仓库提供了一个服务工作者，以实现 Web 应用的离线功能。此外，还提供了一些更小的地图版本，如无边界版本和无城市标签版本，以及包含不同数量城市的版本。

如果需要定制地图或实现网站的离线功能，请联系他们。地图数据遵循 ODB（Open Database License）许可，需要进行归属。

HN 评论 57 comments | 作者：bopjesvla | 12 hours ago #

https://news.ycombinator.com/item?id=40104774

  • 评论者认为项目的海岸线细节不足，建议增加海岸线数据，减少城市细分。
  • 有人提出应该根据 Wikidata 的 QRank 选择包括的地点，以确保重要的岛屿也能显示。
  • 评论指出城市细节与海岸线之间的比例偏向于城市，建议调整比例。
  • 有人指出整个国家在加勒比地区缺失，质量控制有问题。
  • 评论者建议在地图上标注首都，即使人口不到 40k。
  • 有人提出应该显示更多主要道路而不是小城镇。
  • 评论者认为项目应该提供更多精确位置，质疑地图的用途。
  • 有人建议根据周围环境调整城市密度，避免过多显示不必要的城市。

I made an open source Windows app to rewind and search everything on screen #

https://tonoko.notion.site/I-made-an-open-source-app-to-rewind-search-everything-happened-on-your-screen-on-Windows-184d1a9d5edb494dba0c2f46d311ec5c

这个项目是一个开源应用程序，旨在帮助用户在 Windows 系统上回放并搜索屏幕上发生的一切。作者灵感来源于 Mac 应用程序 Rewind 和 Black Mirror S1E3 中的概念，其中角色记录他们眼中的一切，旨在回放或搜索计算机屏幕上出现的所有内容。

该应用程序提供了许多额外的好处，包括本地存储的不可更改的个人记忆，恢复软件失败时的工作，追溯下载数据的来源，以及寻找过去被忽视信息的功能。该应用程序使用 ffmpeg 将屏幕录制为小的 15 分钟片段文件，然后通过 Windows 本地 OCR API 和图像嵌入对它们进行索引。

用户可以选择忽略指定的程序或屏幕范围，并通过漂亮的本地 WebUI 界面进行回放或搜索。作者强调隐私，所有操作仅在用户的计算机上进行，不涉及云端。该应用程序是作者出于个人兴趣和使用需求而开发的，可能存在一些小问题，但作者认为它已经足够成熟和稳健。

作者欢迎讨论、提出问题或帮助改进该项目。当前的缺点包括不支持即时回放、ffmpeg 录制时可能会有相当大的内存消耗以及数据存储透明且未加密等。如果想了解更多信息，请查看链接中的中文内容。

HN 评论 96 comments | 作者：haruharuha | 10 hours ago #

https://news.ycombinator.com/item?id=40105371

这篇帖子中的评论观点包括：

    1. 介绍了 DejaView 项目，提供了桌面计算体验的完整记录和回放功能；
    1. 讨论了 DejaView 项目的历史和技术细节，包括 NILFS 文件系统的使用；
    1. 提到了类似项目，如 Memento 和 Apse，以及其他类似功能的工具；
    1. 讨论了对于类似功能的需求和可能的用途，如记录浏览历史、提高记忆等；
    1. 提及了一些关于隐私和安全性的担忧，以及对于类似功能的反对意见。

Two lifeforms merge in once-in-a-billion-years evolutionary event #

https://newatlas.com/biology/life-merger-evolution-symbiosis-organelle/

这篇文章介绍了科学家们目睹了一次千载难逢的进化事件，两种生命形式合并成为一个生物体，拥有其他同类羡慕的能力。这种现象被称为原生内共生，当一个微生物吞噬另一个微生物，并开始像内部器官一样使用它。宿主细胞提供营养、能量、保护和其他好处给共生体，最终它无法独立生存，实际上成为宿主的一个器官，或者在微生物细胞中被称为细胞器。

在地球生命的 40 亿年历史中，原生内共生据信只发生过两次，每次都是进化的重大突破。第一次发生在大约 22 亿年前，一种古菌吞噬了一种细菌，后者成为了线粒体。这种专门的能量产生细胞器使得基本上所有复杂形式的生命得以进化。它至今仍被誉为细胞的“动力之源”。第二次发生在大约 16 亿年前，当一些更先进的细胞吞噬了能够从阳光中获取能量的蓝细菌。这些成为了叶绿体，赋予了一组你可能听说过的生命形式——植物，获取阳光能力以及迷人的绿色。

现在，科学家们发现这种事件再次发生。一种名为 Braarudosphaera bigelowii 的藻类发现吞噬了一种蓝细菌，使它们能够做一些藻类和植物通常无法做到的事情——直接从空气中“固定”氮，并将其与其他元素结合成更有用的化合物。氮是一种关键营养物质，通常植物和藻类通过与保持分离的细菌的共生关系获取氮。最初人们认为 B. bigelowii 与一种名为 UCYN-A 的细菌建立了这种关系，但在仔细检查后，科学家们发现这两者关系更为亲密。

研究团队发现，藻类和 UCYN-A 之间的大小比例在不同相关物种的藻类中保持相似。它们的生长似乎受到养分交换的控制，导致了关联的新陈代谢。研究团队和其他合作者使用强大的 X 射线成像技术观察了活体藻类细胞的内部。这揭示了宿主和共生体之间的复制和细胞分裂是同步的，这是原生内共生正在发挥作用的更多证据。

最后，研究团队比较了孤立的 UCYN-A 内的蛋白质与藻类细胞内的蛋白质。他们发现，孤立的细菌只能产生大约一半它所需的蛋白质，依赖宿主藻类提供其余部分。“这是从内共生体转变为细胞器的标志之一，”Zehr 说。“它们开始丢弃 DNA 的片段，基因组变得越来越小，开始依赖母细胞提供这些基因产物，或者蛋白质本身被运输到细胞内。”

总的来说，研究团队表示，这表明 UCYN-A 是一个完整的细胞器，被命名为氮细胞器。它似乎在大约 1 亿年前开始进化，这听起来像是一个非常长的时间，但与线粒体和叶绿体相比只是转瞬即逝。研究人员计划继续研究氮细胞器，以找出它们是否存在于其他细胞中以及可能产生的影响。其中一个可能的好处是，它可能为科学家提供一个新途径，将固氮能力纳入植物中，以种植更好的作物。

HN 评论 100 comments | 作者：awb | 1 day ago #

https://news.ycombinator.com/item?id=40101290

这篇帖子中的评论观点归纳如下：

教育中应更生动有趣地传授细胞内共生理论，历史上细胞内共生理论早在 1905 年被提出，2000 年代仍在讨论中；

教育系统难以满足每个学生的兴趣和能力，教师面临挑战；

教师是经过专业培训的，教育系统的问题不是由教师引起的；

细胞内共生是罕见事件，有望改变农业；

细胞内共生后代会包含新的细胞器，如线粒体和叶绿体的起源。

Bringing Exchange Support to Thunderbird #

https://blog.thunderbird.net/2024/04/adventures-in-rust-bringing-exchange-support-to-thunderbird/

在这篇名为《Adventures In Rust: Bringing Exchange Support To Thunderbird》的文章中，作者 Heather Ellsworth, Ikey Doherty, Sean Burke, Brendan Abolivier 介绍了 Thunderbird 将原生支持 Microsoft Exchange Web Services (EWS)，并且所有代码都是用 Rust 语言编写的。文章提到，Microsoft Exchange 是许多公司和教育机构选择的电子邮件服务，因此 Thunderbird 用户对支持 Exchange 的需求很高。在 2024 年 7 月的 Thunderbird 的下一个 ESR（Extended Support）版本中，预计将原生支持 Exchange。初始阶段，Exchange 支持将仅涵盖电子邮件功能，日历和通讯录支持将在以后的版本中提供。

文章详细介绍了他们如何实现对 Microsoft Exchange Web Services 邮件协议的支持，以及从这次冒险中获得的知识将如何指导他们未来的工作。作者还提到了 Thunderbird 项目的历史背景，指出 Thunderbird 的邮件协议支持架构早于 Thunderbird 项目本身，而且在过去的 20 年中从未添加过对新邮件协议的支持。

文章还解释了为什么选择 Rust 作为新协议支持的语言，并列举了 Rust 带来的一些重要好处，如内存安全性、性能、模块化和生态系统等。作者还分享了在引入 Thunderbird 中的第一个 Rust 组件时遇到的挑战，特别是与 Thunderbird 庞大的代码库相关的技术障碍。

最后，文章介绍了他们如何使用 Rust 实现对 Microsoft Exchange Web Services (EWS) API 的支持，包括发送 HTTP 请求、处理 XML 请求和响应等技术细节。作者还提到了他们接下来的计划，包括测试、改进错误处理、扩展支持等方面的工作。文章以总体流程图的形式展示了如何进行 Exchange 请求和处理响应的逻辑流程，并展望了未来的工作方向。

HN 评论 137 comments | 作者：campuscodi | 1 day ago #

https://news.ycombinator.com/item?id=40100672

评论中的观点归纳如下：

    1. EWS 是实现 Exchange Online 和本地安装的最佳方式，Graph API 支持较窄，但 EWS 在短期内对广泛用户群体和长期支持本地安装用户有价值；
    1. Thunderbird 是唯一值得使用的 Windows 邮件客户端，特别适合开发人员；
    1. 许多公司使用本地 Exchange，需要支持不同操作系统的团队，Linux 用户在本地 Exchange 环境下面临困境；
    1. Exchange Online 和 Office 365 仍然有市场，但可能会面临挑战；
    1. Rust 语言在开发中的应用引发了一些争议，有人认为应该优先考虑实现功能而非语言选择；
    1. Thunderbird 对 Exchange 支持的需求引发了讨论，有人认为应该优先支持其他功能。

Racket Language #

https://racket-lang.org/

Racket 是一种编程语言，最新版本为 8.12。它是一种成熟、实用、可扩展、稳健且精致的语言。

Racket 支持面向语言的编程，提供了许多不同的语言，如 Racket/gui、Typed Racket、Scribble/base 和 Datalog。Racket 还支持小型宏、通用宏、易用的领域特定语言（DSLs）、IDE 支持和任何语法。Racket 拥有丰富的生态系统，包括软件、教程与文档、社区、书籍、教育和周边产品。

此外，Racket 还感谢多个组织和个人多年来对其慷慨的支持，如 NSF、DARPA、美国教育部高等教育改进基金（FIPSE）、Exxon 基金会、Microsoft、Mozilla、Google 等。

HN 评论 98 comments | 作者：swatson741 | 20 hours ago #

https://news.ycombinator.com/item?id=40102912

评论中的观点归纳如下：

  • 有人喜欢 Racket 的编译器、包管理系统、GUI IDE 等功能，认为 Racket 是最喜欢的 Lisp 语言之一。
  • 有人认为 Racket 在教学编程方面表现出色，易于理解递归等概念。
  • 有人指出 Racket 的 REPL 不如 Common Lisp，但喜欢 Racket 的干净环境。
  • 有人赞赏 Racket 的 GUI 解决方案。
  • 有人认为 Racket 是一种功能丰富的 Lisp 语言，适合构建网站、GUI 等应用。
  • 有人提到 Racket 的易用性、GUI 开发、文档编写等优点。
  • 有人认为 Racket 在教学方面表现出色，有助于理解递归等概念。
  • 有人认为 Racket 缺乏推广和市场宣传，导致在行业中应用较少。
  • 有人认为大学教育应注重教授学习和思考的能力，而非仅仅是就业培训。
  • 有人认为 Racket 的学习方式有助于提升问题解决能力，胜过只学习传统的面向对象编程语言。
  • 有人认为 Racket 在 CS 教育中表现出色，有助于学习解决问题的方法。
  • 有人认为大学教育的目标是教会学生如何学习和思考，Racket 在这方面表现出色。

I love programming but I hate the programming industry #

https://www.deathbyabstraction.com/I-love-programming-but-I-hate-the-programming-industry

这篇文章探讨了作者对编程行业的看法。作者表示自己热爱编程，但对编程行业感到厌恶。

他认为自己在软件工程工作中从未真正适应。他对设计决策和工作方式产生了疑问，希望能够做出改变而不是延续现状。作者对创业公司和传统科技公司都持有批评态度，认为它们过于注重产出代码而忽略了问题的重要性。

他指出，技术人员往往被要求只关注“如何”，而很少关注“为什么”，这限制了他们的批判性思维。作者强调了创新应该源于社会需求，而不是为了技术本身的进步或人为创造市场需求。

最后，作者表达了希望找到志同道合的人一起创造更有意义的工作环境的愿望。

HN 评论 178 comments | 作者：conquestofdread | 11 hours ago #

https://news.ycombinator.com/item?id=40105121

评论中的观点归纳如下：

  • 有人认为企业界不关心代码的精致、抽象性、机智或美丽，而更关注经济效益。
  • 有人认为快速解决问题比慢慢优美地解决更重要。
  • 有人认为快速而粗糙的代码可能会带来更多机会，而慢慢而美丽的代码可能会导致维护困难。
  • 有人认为在开发软件时，理解客户需求至关重要。
  • 有人认为大部分软件开发是为了发现最小可行产品，而不是纯粹的软件开发。
  • 有人认为企业界更关注代码的美学观念，而不是代码的实际工作性能。
  • 有人认为在软件开发中，清晰的代码比美学观念更重要。
  • 有人认为在软件开发中，技术债务的积累会导致后续问题。
  • 有人认为软件开发是经济活动，而且是一种剥削性的活动。
  • 有人认为软件开发是一种创造性的工作，但大部分时间都花在无意义的会议和琐事上。
  • 有人认为寻找有意义的工作比高薪更重要。
  • 有人认为在小公司工作可能会提供更多自由度和有意义的工作。
  • 有人认为独立开发、追求自己的想法并将其销售给消费者可能是一种解决方案。
  • 有人认为转型为独立游戏开发者需要一定的资金支持，但可以通过游戏销售维持生计。
  • 有人认为在独立游戏开发领域，使用 Playdate SDK 和 Lua 代码进行开发。
  • 有人认为在软件开发中，有时需要权衡速度和质量，但这种权衡并不适用于长期工作。

Doom-htop: The classic DOOM game over htop #

https://github.com/0x0mer/doom-htop

这个项目是一个名为 doom-htop 的开源项目，它将经典游戏 DOOM 的图形呈现在 htop 这个基于文本的进程查看器上。

项目作者创建了一个简单的图像转 ASCII 字符的转换器，并将其嵌入到 htop 中，使得在 htop 界面上能够显示 DOOM 游戏的图形。项目的实现方式是通过 fork 进程并在每个进程中创建共享内存段，然后将图像的每一行复制到相应进程的内存段中。

此外，项目还包括一个简单的键盘记录器，以确保游戏在后台持续运行。项目作者提供了详细的构建和运行说明，同时也提到了一些可能出现的故障和解决方法。

该项目主要在 Ubuntu 22.04 上进行测试，作者鼓励其他用户在不同平台上进行移植。项目遵循 Freedoom 和 GPL 许可协议。

HN 评论 35 comments | 作者：thunderbong | 13 hours ago #

https://news.ycombinator.com/item?id=40104410

评论中的观点归并如下：有人提到了将 Doom 整合到其他应用中的趋势，认为接下来应该将日常应用整合到 Doom 中；有人赞赏这种创意和技术精神，认为这种项目展示了黑客精神仍然存在；还有人觉得这个项目很有趣，称之为“纯粹、美妙的疯狂”。