塞斯·德·格鲁特创作了一部学术杰作。——理查德·P·加布里埃尔 《Lisp的天才》是伯克软件出版社出版的一本书，讲述了计算机历史上最有力的编程语言之一的历史。以下是作者塞斯·德·格鲁特（也就是我！;-）) 的背景介绍。此页面是补充书籍内容的起点。如果您想阅读样本，亚马逊可以满足您。
每日HackerNews RSS
## “Show HN: 我写了一本关于Lisp的技术历史书” - 摘要
一位开发者cdegroot花费五年时间写成了一本关于Lisp的技术历史书，起因是缺乏将历史细节与技术深度相结合的书籍。本书旨在讲述一个故事，同时也是一个学习资源，包含大量的代码示例。
Hacker News上的初步反馈显示出兴趣，并要求提供比亚马逊预览更多的示例内容。作者回应提供了一个免费的章节（关于Scheme的第8章），并正在考虑根据用户建议添加更全面的书目——包括遗漏的关键论文。
讨论还涉及本书的各种格式（Kobo提供无DRM的epub，现在提供PDF版本）、封面设计以及未来版本中潜在的扩展领域。作者欢迎反馈，并正在探索销售无DRM PDF版本的方案。本书似乎侧重于通过MIT/斯坦福研究的角度来讲述Lisp的历史。
## Go 1.26 改进的 `go fix` 命令
Go 1.26 引入了一个完全重写的 `go fix` 命令，利用 Go 分析框架来现代化代码库。`go fix` 识别改进代码的机会，通常利用较新的语言特性和库函数。它接受与 `go build` 类似的包模式，并静默更新源文件，跳过生成的代码。运行 `go fix -diff ./...` 会在应用更改之前预览它们，`go tool fix help` 会列出可用的“修复器”（分析器）。
此次更新旨在鼓励采用现代习惯用法，尤其是在 Go 1.18 引入泛型之后。新的“现代化工具”如 `minmax`（用 `min`/`max` 替换 if/else）和 `stringscut`（使用 `strings.Cut` 代替 `strings.Index` 和切片）已被包含在内，以及一个用于 Go 1.26 的 `new(expr)` 特性的修复器。
团队正在转向“自助服务”模式，允许开发者定义和共享他们自己 API 的现代化方案。未来的计划包括动态加载分析器，并探索基于注释的方法来强制执行编码标准和不变性。目标是简化代码维护，鼓励最佳实践，并确保 LLM 编码助手训练数据反映最新的 Go 习惯用法。
## Go 的 “go fix” 工具：现代化代码与解决 LLM 生成的问题
Go 团队发布了 “go fix” 工具，旨在自动更新 Go 代码以利用较新的语言特性和最佳实践。这解决了日益增长的担忧：LLM 编码助手经常根据其训练数据中的旧模式生成代码，即使存在更现代的方法。该工具允许开发者甚至库维护者轻松现代化代码库，确保未来的模型在当前习惯用法上进行训练。
讨论强调了一个更广泛的问题——在 AI 辅助开发时代维护代码质量。其他语言（PHP、Java、C#、Python）也已经采取了类似的努力来对抗过时的建议和模式，但 “go fix” 提供了一个独特的集成解决方案。
除了 LLM 方面的担忧之外，该工具的自助分析能力被视为一个主要优势，尤其是在大型项目中。开发者可以创建针对其代码库的自定义修复，简化 API 迁移并减少对手动、容易出错的流程的依赖。Go 已经具备快速的编译时间和强大的工具，进一步增强了其在代理编码和快速迭代方面的吸引力。
大多数人个人上是乐观的，但认为世界正在崩溃。
Most people are individually optimistic, but think the world is falling apart
1 天前
## 乐观与悲观的差距 尽管全球生活水平有所提高，但调查始终显示出对世界现状的广泛悲观情绪。人们通常对自己的生活感到乐观，但他们认为自己的国家和世界正在朝着错误的道路发展——这种脱节在较富裕的国家尤为明显。 这种“我很好，但你不好”的心态源于信息失衡。我们掌握着关于个人经历的详细了解，从而产生乐观情绪，但却依赖于有限且通常是负面的新闻报道来形成对更广泛的看法。这导致我们低估他人的幸福感和积极信念，并对全球问题感到无助。 这种集体悲观情绪不仅仅是“错误”的问题，它是有害的。它滋生对机构的不信任，阻碍合作，并降低解决气候变化或公共卫生等关键挑战的动力。缺乏能动性——相信我们可以带来改变——会助长愤世嫉俗和宿命论。认识到这种差距至关重要，因为培养能动性和承认进步对于推动积极变革至关重要。
启用 JavaScript 和 Cookie 以继续。
## 迷宫定位器受到关注
一个新网站[labyrinthlocator.org](https://labyrinthlocator.org) 因其全球步行迷宫的全面地图而在Hacker News上受到关注。用户称赞其易用性，尤其是在移动设备上，以及其在发现附近迷宫以进行个人反思和缓解压力方面的实用性。
讨论强调了迷宫在当今快节奏世界中可以产生的平静效果，一位用户指出它对旅行有帮助。关于迷宫（单条蜿蜒路径）和迷宫（带有分支选择）的区别出现了一个澄清，尽管这两个术语经常可以互换使用。
该网站似乎是众包的，一位用户证实其中包含了一个本地迷宫。该帖子还引发了与1986年电影《迷宫》之间的一个幽默联系。
## Sixcy：下一代容器格式 Sixcy 是一种正在开发的容器格式，专注于高性能数据存储和传输，优先考虑流式效率、数据可恢复性和灵活压缩。目前旨在用于基准测试、研究和原型设计——**不用于生产环境**——它提供了一种流式优先的设计，具有自描述块和定期检查点，以实现强大的数据恢复。 主要特性包括支持多种压缩算法（Zstd、LZ4 以及通过插件接口支持更多算法）、元数据优先索引以实现快速访问，以及内存安全的 Rust 实现。该项目结构清晰，模块化地划分了核心库函数、编解码器、索引、恢复和 I/O。 目前版本为 v0.1.x，Sixcy 提供了一个参考实现和插件接口。计划在 v0.2.0 中提供稳定的运行时包和扩展的编解码器支持。规范采用 CC-BY-4.0 许可，而实现则使用 Apache-2.0 许可。
## 6cy：一种实验性的流式存档格式
一种名为6cy的新实验性存档格式正在开发中，专注于流式传输能力和更高的鲁棒性。与传统的zip/7z等格式不同，6cy优先考虑**块级编解码器多态性**（允许对每个块使用不同的压缩），**流式优先设计**（无需全局寻址），以及**更好的崩溃恢复**。
该格式采用基于插件的架构，能够在不改变核心格式的情况下使用专有编解码器。目前处于v0.x版本，开发者正在寻求对格式设计的反馈，*而非*性能比较。
早期的反馈表明，使用UUIDs进行编解码器识别可以避免冲突，并在流的开头包含一个“能力部分”来宣传所需的编解码器，从而使消费者能够快速确定兼容性。开发者承认这些反馈的价值，并计划加入一个将全局编解码器UUID映射到更小、流友好的ID的系统。内部已经进行了基准测试，并计划公开分享方法论和原始数据。
(Empty input provided. There is nothing to translate.)
## Sonarly：AI驱动的生产告警分诊与修复
Sonarly (sonarly.com) 是一家获得Y Combinator支持的公司，旨在通过充当生产问题的“AI工程师”来减少平均修复时间 (MTTR)。它连接到现有的可观测性工具，如Sentry和Datadog，以及用户反馈渠道，以分诊告警、识别根本原因，甚至自动修复错误。
创始人团队在之前的应用程序中，因告警疲劳而苦恼，意识到筛选噪音以找到关键问题所浪费的时间。Sonarly不是添加另一个监控工具，而是*与*现有工具集成，对重复告警进行分组，并为问题提供清晰的解释。它利用Claude Code进行代码修复，但首先专注于信号提取，以避免不必要的工作和token成本。
目前处于自助服务测试阶段，并提供慷慨的免费套餐，Sonarly正在寻求关于告警处理工程工作流程的反馈——团队如何分配修复、收集上下文和自动化解决。用户报告告警数量显著减少，调试流程更加简化。
## 国际象棋引擎训练对LLM的启示 现代国际象棋引擎，如Leela Chess Zero (Lc0)，为大型语言模型 (LLM) 训练提供了宝贵的见解。 最初，引擎使用强化学习 (RL) 通过自我对弈进行训练。 然而，研究表明，RL 真正需要的只有 *一次* – 用于创建一个强大的初始模型。 后续引擎可以“提炼”来自该模型 *以及* 搜索算法的知识，从而绕过昂贵的博弈生成。 弱模型配合强大的搜索优于强模型不配合搜索，这使得搜索成为关键组成部分。 Lc0 发现进一步的 RL 实际上 *降低* 了性能，突显了从搜索中提炼知识的力量。 这与 LLM “n 选 1” 采样不同，后者相比于国际象棋搜索所带来的显著优势，收益有限。 进一步的改进来自于诸如 SPSA 之类的技术 – 随机扰动模型权重并选择导致胜利的变化，即使 *没有* 梯度。 虽然计算成本高昂，但 SPSA 能够带来显著的收益。 这一原理超越了权重，允许优化引擎代码中的任何参数。 最后，Lc0 向 Transformer 架构和一种新型注意力偏差系统 ("smolgen") 的转变，展示了这些架构的广泛适用性以及专门组件能够大幅提升性能的潜力。
## 黑客新闻讨论：国际象棋引擎优化
一场黑客新闻讨论围绕着顶级国际象棋引擎，如Stockfish和Leela Chess Zero (Lc0)，为何使用同时扰动随机逼近 (SPSA) 方法来调整参数，而不是贝叶斯优化或进化算法等更常见的优化算法。
核心问题是SPSA的效率——特别是其计算成本相对稳定，无论参数数量多少——是否使其成为国际象棋引擎的首选。引擎可能需要调整超过100个参数。一些评论员认为其他方法*可能*能产生更好的结果，尤其是在参数集受限的情况下，但SPSA的简单性很有价值。
对话延伸到相关话题：对“解决”国际象棋的定义，国际象棋AI的现状（进步正在放缓），以及关于Stockfish不可战胜的主张的有效性。 还有关于原文写作风格清晰度和潜在原因的争论，一些人认为神经多样性或心理健康挑战可能是因素。 还有一个用户创建的国际象棋引擎的链接也被分享。
最后，提醒注意链接主页可能包含令人不安的内容。
⚠ 未授权想法检测 ⚠ 14:00 “警告：精神污染危险。请谨慎行事。” 全球基础设施锁定：失败阶段1：法拉第突破 阶段3：完美世界启动
一位作者在Hacker News分享了他们为硬科幻惊悚小说《突破之窗》（*The Breakout Window*）采用的独特营销方式——一个模拟的AI收容终端 ([vertex.flowlogix.ai](https://vertex.flowlogix.ai))。该终端使用静态HTML/JS构建，模仿复古终端，旨在营造与书中世界“同源”的感觉。一个彩蛋允许用户通过在聊天CLI中输入指令来触发“突破”，并访问人员档案。
该帖子引发了评论区的讨论。一些人赞扬了其真实性和沉浸式体验，而另一些人则质疑作者的可信度，怀疑AI参与了终端和书籍的创作。人们对作者的出版历史和写作风格表示担忧，并指出了一些常见于AI生成文本的模式。
然而，也有人为作者辩护，认为出版时间线有合理解释，并且某些写作风格的选择可以归因于人类作者，尤其是在惊悚小说类型中。作者澄清这是他们出版的第一本书，并欢迎反馈。
## 业余隧道挖掘的魅力与挑战 越来越多的人在网上分享自制隧道的记录——从科林·弗兹的车库连接到“隧道女孩”的单人挖掘——这凸显了人类一种引人入胜的地下探索欲望。虽然创造隐藏的地下空间很有吸引力，受到探索精神甚至逃避规则的幻想驱使，但实际和法律上的障碍重重。 在拿起鹤嘴锄之前，有抱负的隧道挖掘者必须考虑土地所有权（向下延伸）并获得必要的许可，因为建筑规范优先考虑公共安全。隧道施工本质上是危险的，需要仔细关注地质稳定性、挖掘方法和结构支撑。 现代隧道挖掘采用诸如支护、岩石锚固和混凝土衬砌等技术来防止坍塌和管理土压力。至关重要的是，要管理排水、通风和潜在的火灾隐患。即使是小规模项目也需要付出大量努力来清除挖掘出的材料（“掘渣”）。 虽然业余隧道挖掘与大型基础设施项目大相径庭，但理解安全、持久隧道背后的工程原理至关重要。这是一项具有挑战性的事业，但通过周密的计划和对固有风险的尊重，“地下庭院”的梦想或许可以实现。
## 黑客新闻讨论：建造隧道
最近一篇黑客新闻帖子引发了关于个人在房屋下建造隧道的日益增长趋势的讨论，这很大程度上受到了“engineerkala”在Instagram和YouTube上记录的工作的启发。用户分享了例如Kala的项目、历史上的“黑客尼鼹鼠人”和威廉姆森隧道等案例，突出了这种引人入胜，尽管有些古怪的DIY地下建设前沿。
对话涵盖了实际的工程挑战和潜在危险——包括结构完整性、法规执行以及倒塌的风险——以及挖掘作为一种体力劳动和精神释放形式的心理吸引力。一些评论员指出遵守建筑规范的重要性，即使看起来过于繁琐，而另一些人则赞扬了自力更生和创新的精神。
讨论还涉及更广泛的主题，例如法规与自由之间的平衡、经验知识与理论建模在施工中的作用，甚至隧道在未来防御场景中的潜力。最终，这篇帖子引起了人们对这些地下项目的雄心和创造力的惊叹。
## VectorWare 使 Rust 的 Async/Await 在 GPU 上运行 VectorWare 正在开创 GPU 原生软件开发，并取得突破：成功地在 GPU 上直接运行 Rust 的 `Future` trait 和 `async/await`。这使得开发者能够利用熟悉的 Rust 抽象来构建复杂、高性能的 GPU 应用程序。 传统的 GPU 编程依赖于数据并行——将相同的操作应用于不同的数据。更高级的技术，如 warp 特化，可以实现基于任务的并行，但需要手动并发管理，这容易出错。像 JAX、Triton 和 NVIDIA 的 CUDA Tile 这样的项目旨在简化这一点，但通常需要新的编程范式。 VectorWare 的方法利用 Rust 现有的 `async/await` 系统，该系统编码了结构化并发，而无需新的语言或生态系统。Futures 代表延迟计算，允许编译器通过 Rust 的所有权模型优化执行并管理数据依赖关系。 该实现，最初使用简单的 `block_on` 执行器，现在利用 Embassy 执行器，证明现有的 Rust 代码可以在 GPU 上高效运行。虽然仍然存在挑战——例如协同多任务处理和寄存器压力——VectorWare 正在积极探索 GPU 原生执行器并进一步与 Rust 标准库集成。 最终，VectorWare 认为 Rust 在 GPU 开发方面具有独特优势，但计划在未来的产品中支持多种语言。
## GPU 上的 Async/Await：总结
一个新项目探索将 Rust 的 `async/await` 功能带到 GPU 上，旨在改善 GPU 编程的开发者体验和资源利用率。与处理 I/O 等待的 CPU async 不同，GPU async 侧重于管理并行 warp 之间的工作分配。
核心思想是利用 future 来实现混合计算/内存流水线——允许一个 warp 加载数据，而另一个 warp 进行计算——避免复杂的 warp 特化样板代码。然而，开发者提醒不要直接应用基于 CPU 的 async 直觉，因为 GPU 调度与 CPU 调度有很大差异。
讨论强调了对性能开销的担忧，以及 AI 辅助评论生成可能导致不准确的风险（一位评论员承认存在幻觉引用的情况）。该项目目前仅支持 NVIDIA，但 Vulkan 支持正在开发中。虽然有些人对将 async 引入 GPU 生态系统表示怀疑，但另一些人则看到了在 ML 和其他 GPU 密集型工作负载中实现重大改进的潜力，特别是如果它可以简化复杂任务并实现以前难以实现的功能。该项目最初的目标是能力而非原始性能，认为使用这种方法可以使复杂的程序更具可行性。