这份摘要评估了遵循“简洁代码”（Clean Code）准则（如多态、短函数和面向对象封装）所带来的性能成本。作者通过将这些“简洁”实现与传统的面向数据方法进行对比，并使用标准的形状计算示例，证明了行业内的通用做法可能会导致显著的运行时性能下降。 尽管“简洁代码”的倡导者认为这些规则能提高可维护性，但作者指出，遵循这些规则——特别是用类层次结构和虚函数调用来取代高效的数据结构和分支语句——引入了不必要的间接性。这些模式阻碍了编译器进行有效的优化，导致性能比面向数据的替代方案慢 10 到 25 倍。 最终，作者认为这些架构选择以微不足道的可读性提升为代价，牺牲了十多年来的硬件进化成果。文章得出结论，由于这些方法论，软件性能被不必要地降低了。作者建议，虽然代码组织很重要，但开发人员必须拒绝那些对编译器隐藏数据结构和逻辑的“简洁”规则，因为其速度成本高昂，难以证明其合理性。
每日HackerNews RSS
文章《整洁代码，性能糟糕》（Clean Code, Horrible Performance）引发了关于“整洁代码”原则与系统性能之间权衡的激烈争论。
批评者认为，该书推崇对规则的教条式遵循——例如过度的函数拆分、多态和僵化的抽象——这往往会掩盖逻辑、增加认知负荷，并因缓存未命中和不必要的间接调用引入显著的性能开销。许多开发者认为，这些“整洁代码”准则往往是在真空状态下应用的，忽略了硬件架构和特定领域复杂性的现实。
拥护者或态度更温和的人士则建议，这些原则应被视为启发式方法而非绝对定律。他们主张性能与可维护性并非相互排斥；相反，目标应该是编写出高性能的“简单”代码，开发者应运用“工程判断力”来选择何时优先考虑灵活性，何时优先考虑效率。
归根结底，这场讨论反映了人们对盲目照搬（cargo-culting）编程模式的广泛不满。各方达成共识：最有效的方法是编写尽可能简单的代码，仅在必要时进行优化，并意识到若不顾语境盲目遵循任何方法论，往往会导致软件既无性能也难维护。
1582年，天主教世界从儒略历过渡到格里高利历，以纠正长久以来的历法偏差。为使两个系统对齐，10月5日至10月14日这十天被正式从历史中删除。因此，在格里高利历中，这些日期并不存在。 本文探讨了现代编程语言如何处理这些“不存在”的日期。Ruby 能正确拒绝创建该时段的格里高利历日期，但 Python 和 Perl 均未能将其标记为无效，允许程序员实例化这些不可能存在的日期。 作者以此案例强调了日期和时间实现中精确性的重要性。他指出，虽然 `ncal` 等工具试图考虑不同地区采用格里高利历的历史差异，但对于软件开发者而言，实现完美的历史准确性仍然是一项复杂的挑战。
本次讨论探讨了因从儒略历转向格里历所导致的“不存在”日期这一复杂问题。核心技术结论是：大多数编程库使用**前推格里历（proleptic Gregorian calendar）**，即默认将现行的格里历规则无限向过去延伸。这种做法简化了计算，但对历史学家和数据库工程师而言却产生了逻辑上的不一致，因为它忽略了各国实施历法改革的具体“过渡日期”（例如天主教欧洲为 1582 年，英国及美国为 1752 年）。
辩论中的关键点包括：
* **表示误差：** 简单地跳过日期（正如格里历改革所做的那样）会使日期运算变得困难。有人建议使用在特定历史节点拼接儒略历和格里历规则的“复合历法”。
* **“纪元”解决方案：** 专家强调，内部日期时间处理应依赖明确的数字时间戳（如 Unix 时间戳），仅在面向用户的输出时才使用特定历法的逻辑。
* **背景至关重要：** 由于全球各地的采纳日期不同，历史准确性不仅取决于日期本身，还需要了解文档的地理和法律背景。
综上所述，尽管前推格里历是现代软件的标准，但将其应用于历史事件时，它仍然是一个“虚构”的框架。
```rust use std::collections::HashMap; enum Data<K, V> { Value(V), KeyValue(K, V), } fn main() { let data = vec![ Data::KeyValue("Steve", 10), Data::Value(20), Data::KeyValue("Bill", 30), Data::Value(40), ]; let map = data .into_iter() // 模式匹配与解构 .map(|item| match item { Data::KeyValue(k, v) => { println!("{k}: {v}"); (k.to_string(), v) } Data::Value(v) => { println!("unknown: {v}"); ("unknown".to_string(), v) } }) // 将项累加到 map 中 .fold(HashMap::new(), |mut map, (key, value)| { map.entry(key) .and_modify(|existing| *existing += value) .or_insert(value); map }); println!("Map: {:?}", map); // Map: {"unknown": 60, "Bill": 30, "Steve": 10} } ```
在这篇2012年的文章中，作者伊恩·利尔蒙斯（Iain Learmonth）讲述了他被困在故障公寓电梯里的惊魂经历。尽管他向阿伯丁市议会缴纳了维护费，但利尔蒙斯发现电梯的警报按钮形同虚设，只会发出声响，却无法通知紧急服务部门或大楼管理处。 被困在屏蔽信号的金属箱里，利尔蒙斯在移动网络信号差和社交媒体求助失败的困境中挣扎。然而，当电梯运行至他家Wi-Fi的覆盖范围时，他成功利用 **mosh**（移动终端）连接到了 SDF MetaArray。由于 mosh 是为处理高丢包率而设计的，它使他能够通过终端发送电子邮件，从而促使消防队赶到现场。 尽管电梯在救援人员被召唤时又自行恢复了工作，但这番折磨还是让利尔蒙斯对大楼的基础设施失去了信任。他在文章结尾幽默地写道，他计划增强家里的Wi-Fi信号，以确保如果再次被困，至少还有一种可靠的方式可以寻求帮助。
2026年8月4日，一起重大供应链攻击事件导致多个常用 npm 包（包括 `keyv`、`flat-cache` 和 `file-entry-cache`）的关键维护者 GitHub 账户被攻破。攻击者通过直接向主分支推送恶意代码，发布了带有有效来源签名（provenance signatures）的受损版本，影响了超过 868 个软件包，这些软件包的月下载量总计达数十亿次。 此次攻击表现为一种自我传播的蠕虫病毒。一旦受害者运行 `npm install`，一个经过混淆的投放脚本（`setup.mjs`）就会执行并安装 Bun 运行时，随后运行有效载荷（`Math_Symbol.js`）。该有效载荷旨在积极窃取敏感数据，包括： * **令牌与密钥：** npm、GitHub、AWS、Stripe、Slack 和 HashiCorp Vault 的凭据。 * **基础设施访问权限：** Kubernetes 机密信息和本地环境变量。 * **系统文件：** SSH 密钥、私钥、`.env` 文件和 VPN 配置。 该蠕虫还会针对其他维护者进行感染扩散。强烈建议用户检查其依赖项、执行安全扫描，并对这一针对软件供应链的自动化、高影响威胁保持警惕。
一项被称为“Shai-Hulud”的活跃供应链攻击已波及超过 2,000 个 NPM 软件包，影响了每月数十亿次的安装。该恶意软件利用 `preinstall` 脚本执行一个经过高度混淆的释放程序（`setup.mjs`），进而下载并运行恶意负载（`Math_Symbol.js`）。此负载旨在窃取敏感的环境密钥，通过公开的 GitHub 仓库泄露这些数据，并进一步感染其他开发者的机器。
此次攻击在 Hacker News 上引发了关于软件安全的热烈讨论，讨论的主要要点包括：
* **缓解策略：** 专家建议实施“依赖冷却期”（在采用新版本前等待几天）、使用不具备发布权限的隔离 CI/CD 工作流，以及禁用自动依赖更新。
* **系统性弱点：** 评论者强调了安装过程中执行任意代码的危险，以及 JavaScript 生态系统中过度依赖所固有的风险。
* **安全工具：** 讨论强调了纵深防御的重要性，提倡使用诸如用于密钥注入的本地代理、静态/动态分析工具（如 Packj），以及严格隔离构建与测试环境。
* **注册中心责任：** 人们对 NPM 和 GitHub 等主要注册中心仍未针对此类广泛的自动化攻击实施更强大、更主动的检测表示强烈不满。
Homebench – 测试本地大模型在速度、内存及质量方面的表现 Homebench – Benchmark local LLMs for speed, memory, and quality
4 天前
**homebench** 是一款零配置、以本地优先为核心的工具，旨在您的个人硬件上对大语言模型（LLM）进行基准测试。它填补了单纯的速度测试与复杂评估框架之间的空白，并提供了一个实时终端用户界面（TUI），以便从质量、速度和内存占用等方面对模型进行对比。
### **主要功能**
* **统一基准测试：** 自动发现来自 Ollama、LM Studio、llama.cpp、vLLM 或任何兼容 OpenAI 协议服务器的模型。
* **综合指标：** 测量每秒生成 Token 数（tokens/sec）、首字延迟（TTFT）以及内存占用情况。
* **质量评估套件：** 包含 31 个确定性任务，涵盖数学、推理和代码编写。可选的“LLM 裁判”模式可用于评估开放式任务。
* **硬件分析：** 提供 `fit` 命令，根据您的内存/显存（RAM/VRAM）容量评估哪些模型适合在您的系统上运行。
* **开发者友好：** 功能包括自动保存结果历史、运行结果差异对比、批量吞吐量测试，并支持自定义任务包（JSON/YAML）。
### **入门指南**
通过 pip 安装：`pip install homebench`
**快速使用：**
* `homebench`：运行快速默认基准测试。
* `homebench --all --full`：对所有模型进行全面的基准测试。
* `homebench fit`：检查哪些模型适合您的特定硬件。
`homebench` 是开源的，要求 Python 3.9+ 环境，能够为优化您的本地 LLM 设置提供即时、可操作的数据。
在多线程编程中，顺序锁（sequence locks）提供了一种非阻塞锁的替代方案，但它存在一个关键缺陷：在并发访问期间复制非原子数据会导致 Rust 和 C++ 中的未定义行为（UB）。检测到竞争条件并不等同于防止复制过程中发生的非法内存访问。
为了解决这个问题，**iceoryx2** 库引入了 `ByteAtomic`，这是一个能够实现字节级原子读写操作的封装器。它通过确保内存复制是逐字节进行而非作为单一非原子单元执行，从而避免了未定义行为。
该实现通过利用自定义的 `AtomicCopy` 特性，克服了未初始化内存（填充字节）带来的风险。该特性允许系统识别并仅复制数据结构中已初始化的字段，从而安全地跳过未初始化的间隙。
虽然 `ByteAtomic` 防止了内存复制带来的未定义行为，但它本身无法保证逻辑数据的完整性；用户仍需使用同步机制（如顺序锁）来防止“撕裂读取”（torn reads）。`ByteAtomic` 为在传统锁无法满足需求的系统中构建可靠、高性能的无锁结构，提供了必要的基础安全机制。
这篇 Hacker News 讨论聚焦于 `iceoryx2` 团队发布的一篇关于“ByteAtomic”封装的文章，该封装旨在安全地执行并发内存拷贝。
作者解释称，在 Rust 中，即使使用了顺序锁来丢弃损坏的结果，当发生数据竞争时，标准的 `memcpy` 操作也会触发未定义行为（UB）。他们的解决方案提供了一种在不违反语言安全保证的前提下执行这些拷贝的方法。
社区讨论主要集中在以下三个方面：
1. **实用性与理论的权衡**：批评者认为，“未定义行为”问题属于语言层面的技术细节，硬件层面可以处理得很好。他们认为强制执行逐字节的原子操作会显著降低性能。
2. **同步定义的界定**：关于术语出现了技术分歧——特别是无锁（lock-free）、无等待（wait-free）和顺序锁（sequence locks）之间的区别，以及考虑到顺序锁在写入者被中断时可能导致阻塞，探讨了其在安全关键系统中是否适用。
3. **替代方案**：资深开发人员建议，对于共享内存通信，RCU（读-拷贝-更新）或指针交换等替代模式通常比字节级原子封装更高效且更合适。
arXivLabs 是一个允许合作者直接在我们的网站上开发和共享 arXiv 新功能的框架。与 arXivLabs 合作的个人和组织都认同并接受我们关于开放、社区、卓越和用户数据隐私的价值观。arXiv 致力于坚守这些价值观，并仅与遵守这些价值观的合作伙伴进行合作。如果您有能为 arXiv 社区增值的项目想法，欢迎了解更多关于 arXivLabs 的信息。
为何词源很重要：追溯词源如何照亮历史 (2024) Why etymologies matter: How tracing words can illuminate history (2024)
4 天前
作为一名在波斯语与英语双语家庭中抚养孩子的历史学家，本杰明·布林（Benjamin Breen）探讨了词源学如何成为连接遥远过去与现代生活的桥梁。
通过考察语言中的“同源词”（即跨越遥远距离、拥有共同词根的词汇），布林展示了我们之间深刻且常被忽视的相互联系。他追溯了波斯语单词“div”（恶魔）的词源，发现其源自古印欧语中的“神”，由此说明了数千年前的宗教分裂是如何将神灵转变为恶魔的。同样，他还强调了诸如《铁匠与魔鬼》这类古老故事是如何流传数千年的，这表明我们的一些古老民间传说可能早于文字历史。
布林还利用词源学来揭示近期的文化转变，例如“hello”（你好）一词的出现。事实上，“hello”并非古已有之，它直到19世纪后期才成为标准问候语，这是早期电话技术所带来的需求。通过这些例子，布林提出词源学不仅仅是一项智力练习；它更是一种揭示塑造我们当下的“消逝的思想世界”的工具，揭示了当代话语中常被忽视的共有的人类历史。
作者分享了将 Claude 等大语言模型（LLM）整合到专业游戏开发中的经验，其态度从最初的怀疑转变为谨慎且有限的使用。虽然作者拒绝接受围绕人工智能的“魔法”营销，但发现它在处理内部公司文档和复杂、陌生的代码库时，作为研究工具具有一定价值。 然而，作者强烈警告不要依赖大语言模型来编写代码。他们认为这些模型经常产生“幻觉”，提供过度设计或低效的解决方案，并且缺乏深入的技术推理，尤其是在游戏开发这类训练数据通常较差的利基领域。作者指出，大语言模型本质上并不“智能”，它们只是容易生成自信误导信息的统计引擎。 最终，作者认为大语言模型是用于信息检索和新人入职的一种有用但昂贵的辅助手段，而非工程专业知识的替代品。他们批评了管理层强制要求订阅昂贵 AI 服务的趋势，建议企业应优先进行成本效益分析，而非盲从于“平庸产出”的流行语。作者总结道，虽然人工智能可以辅助处理信息，但它无法取代构建健壮、高效软件所必需的第一性原理思考、验证和深厚的领域知识。
这段 Hacker News 讨论聚焦于对 AI 辅助编程的批判性审视，反映了“代理式”（agentic）工作流的支持者与认为现有工具不足以胜任高级软件工程的怀疑论者之间的分歧。
**核心主题：**
* **性能与实用性：** 批评者认为 AI 在游戏开发中的性能优化等专业任务上表现不佳，因为它缺乏对专有技术或高性能限制的深刻理解。相反，支持者认为这些失败往往是“技能问题”，并声称通过适当的系统提示词、“控制框架”（harnesses）和测试驱动的代理循环，AI 可以非常有效。
* **“感觉编程”（Vibecoding）之争：** 许多评论者对那些不经严格审查就推送 AI 生成代码、导致软件质量低下且臃肿的“感觉派程序员”表示不满。另一些人则坚持认为，人类本身就会产出低质量代码，AI 只是放大了这种产出。
* **权力博弈：** 该讨论串突显了对控制权的争夺。尽管工程师抵制企业“恐慌式”推动的 AI 指令，但管理层却为了提升生产力而推行这些工具，往往凌驾于开发者对工作方式的自主权之上。
* **期望差距：** 摩擦多源于大语言模型（LLM）的本质：将 AI 视为专家预言家而感到失望的用户，与将它们视为能起草复杂样板代码的概率性“随机鹦鹉”并认为其不可或缺的用户之间，存在着巨大的认知鸿沟。