EmacsTalk 是一档专注在 Emacs 社区的程序员闲聊节目。M-x thanks-for-listening。官网：https://emacs.liujiacai.net/
EmacsTalk
Claim This Podcastby 写代码的西瓜
5.0(4 reviews)
19 episodes
Updated Daily
Accepts GuestsHas Sponsors
Podcast Overview
EmacsTalk 是一档专注在 Emacs 社区的程序员闲聊节目。M-x thanks-for-listening。官网：https://emacs.liujiacai.net/
Language
🇨🇳
Publishing Since
6/26/2021
1 verified contact email on file for EmacsTalk
Pitch yourself as a guest, propose sponsorships, or reach out directly to the host.
Recent Episodes
March 7, 2026
019. Mitchell Hashimoto 编写代码的新方式
<h4>欢迎听众<a href="https://liujiacai.net/donate/">打赏支持</a>，您的支持是我不断创作的动力🍻 </h4> <ul> <li><a href="https://mitchellh.com/">Mitchell Hashimoto</a></li> <li><a href="https://ghostty.org/">Ghostty</a> 是一款快速、功能丰富且跨平台的虚拟终端仿真器，它使用平台原生 UI 和 GPU 加速。</li> </ul> <div id="outline-container-headline-1" class="outline-3"> <h3 id="headline-1"> AI 总结 </h3> <div id="outline-text-headline-1" class="outline-text-3"> <blockquote> <p><a href="https://newsletter.pragmaticengineer.com/p/mitchell-hashimoto">Mitchell Hashimoto's new way of writing code</a> (2026-02-26, gemini-3-flash-preview)</p> </blockquote> <p> 这是一份基于 Mitchell Hashimoto 近期访谈的深度研报。Mitchell 作为 HashiCorp 的联合创始人，曾主导开发了 Terraform、Vagrant 等改变云基础设施规则的工具。如今他离开管理一线，以独立开发者和观察者的身份，重新定义 AI 时代的编程范式。</p> </div> </div> <div id="outline-container-导读" class="outline-3"> <h3 id="导读"> 1. 导读 </h3> <div id="outline-text-导读" class="outline-text-3"> <p>在硅谷的叙事中，Mitchell Hashimoto 是一个特殊的坐标：他不仅凭借一己之力推动了“基础设施即代码”（IaC）的普及，更在一个工程师驱动的公司里完成了从开源到商业化的艰难跃迁。如今，当行业普遍迷失在 AI 幻觉与生成式代码的狂潮中时，Mitchell 却回归到了最原始的“手艺人”状态——开发一款极致性能的终端 Ghosty。</p> <p> 这场对话不仅是对 HashiCorp 创业史的回溯，更是一次关于“软件工程尊严”的辩论。Mitchell 在这里揭示了他如何与傲慢的云巨头博弈，为什么他认为 AI 正在摧毁开源社区赖以生存的信任体系，以及他如何通过“始终运行一个 Agent”的策略，在效率巅峰期保持着一种近乎冷酷的清醒。读完你会发现，真正的技术变革，往往发生在人类决定“不把时间浪费在什么地方”的那一刻。</p> </div> </div> <div id="outline-container-核心观点" class="outline-3"> <h3 id="核心观点"> 2. 核心观点 </h3> <div id="outline-text-核心观点" class="outline-text-3"> <p>Mitchell Hashimoto 的核心世界观可以概括为：*软件工程的本质正从“编写逻辑”转向“意图调度与约束管理”。* 在他看来，AI 带来的不是单纯的效率提升，而是对软件开发生命周期的重构——从代码的版本控制（Git 的局限）到社区的准入机制（开源信任的崩塌），所有基于“人类精力有限”这一假设建立的旧秩序都在失效。他主张开发者应该像管理一支廉价但不可靠的实习生团队一样管理 AI，将重心从“造物”转移到“构建测试支架（Harness）”上。</p> <div id="outline-container-关键判断" class="outline-4"> <h4 id="关键判断"> 关键判断 </h4> <div id="outline-text-关键判断" class="outline-text-4"> <ul> <li><strong>开源社区的“默认信任”模式已经终结。</strong> Mitchell 指出，AI 让制造“看起来像样但低质量（Slop）”的代码成本降为零。过去开源项目通过观察贡献者的“努力程度”来建立信任，而现在 Agent 可以瞬间提交成百上千个 PR。他断言，所有主流开源项目必须转向“默认拒绝（Default Deny）”和“显式背书（Vouching）”的准入系统，否则会被 AI 生成的垃圾信息淹没。</li> <li><strong>云巨头的性格决定了生态位的生存策略。</strong> 基于多年与 AWS、Azure 和 Google Cloud 的博弈，Mitchell 总结了三大巨头的技术文化：AWS 是极其傲慢且具有掠夺性的（时刻准备用原生产品杀死合作伙伴）；Microsoft 则是极其职业且具备共赢思维的（优先问：我们如何共同获利？）；Google 拥有顶尖的技术审美，却在商业感知上几乎完全失明。这一判断解释了为什么 HashiCorp 必须坚持多云策略，因为中立性不仅是技术需求，更是政治生存。</li> <li><strong>Git 正面临其“Gmail 时刻”。</strong> 现有的 Git 工作流（克隆、分支、合并队列）是为人类的产出速度设计的。Mitchell 观察到，在高度 Agent 化的公司中，代码流转速度提升了 10-100 倍，Git 的性能和冲突解决机制在巨大的代码吞吐量面前开始崩溃。他预言版本控制系统需要从“快照记录”转向“全量上下文索引”，不再允许丢弃任何一次尝试。</li> <li><strong>开发者正进化为“支架工程师（Harness Engineer）”。</strong> Mitchell 提出一个反直觉的习惯：无论是否在写代码，后台始终运行一个 Agent 负责调研或处理琐事。他认为，为了让 Agent 输出高质量结果，开发者 70% 的精力将花在构建“验证环境”和“测试规格书”上。如果 AI 犯了错，不要去修代码，而要去修那个“防止 AI 犯错的支架”。</li> <li><strong>性能是软件工程中最后的“匠心堡垒”。</strong> 在开发 Ghosty 时，Mitchell 执着于将渲染延迟压缩至 10 微秒以内。他承认这在商业上可能“溢出”，但认为在 AI 生成代码泛滥的时代，对底层细节（如 GPU 内存管理、SIMD 指令集）的极致把控，是区分“真正的工程师”与“代码调度员”的唯一标志。</li> </ul> <p>这些观点构成了一个逻辑链条：因为 AI 降低了生产成本（产生垃圾 PR），所以我们必须提高过滤标准（信任背书制）；因为代码生成不再是瓶颈，所以验证代码的正确性（Harness Engineering）和底层运行效率（极致性能）成了新的核心竞争力。</p> </div> </div> </div> </div> <div id="outline-container-批判与质疑" class="outline-3"> <h3 id="批判与质疑"> 3. 批判与质疑 </h3> <div id="outline-text-批判与质疑" class="outline-text-3"> <p>尽管 Mitchell 的论述极具前瞻性，但其体系中仍存在一些值得考量的盲点。</p> <p> 首先，他提倡的 <strong>“显式背书系统（Vouching System）”</strong> 虽然能解决 AI 垃圾贡献问题，但极易导致开源社区的 <strong>精英阶层固化</strong> 。这种类似“Lobsters”社交网站的邀请制，会增加新人入行的隐形门槛，可能扼杀那些非科班出身、缺乏社交资本但有潜力的天才开发者。</p> <p> 其次，他在 AI 工作流中对 <strong>“始终运行 Agent”</strong> 的依赖，隐含了一个未经验证的前提： <strong>开发者具备极强的任务拆解能力和 Review心理阈值</strong> 。普通开发者在面对 Agent 生成的源源不断的代码片段时，极易陷入“决策疲劳”，最终为了追求速度而放弃深度审查。这种“幻觉累积”可能在短期内表现为高产，但在长期维护中会埋下巨大的技术债。</p> <p> 此外，Mitchell 对 <strong>Git 衰落</strong> 的断言虽然激进且有趣，但忽略了工具链的巨大惯性。Git 不仅仅是技术，更是全球软件工业的“共同协议”。即便它在 Agent 协作中效率低下，更有可能的结果是插件式的补丁（如 Merge Queue 的普及）而非彻底的范式更迭。</p> </div> </div> <div id="outline-container-行业视野" class="outline-3"> <h3 id="行业视野"> 4. 行业视野 </h3> <div id="outline-text-行业视野" class="outline-text-3"> <p>Mitchell 的分析将我们带入了一个 <strong>“后开源时代（Post-Open Source Era）”</strong> 。</p> <p> 在行业历史图谱中，这场对话呼应了 2010 年代初从“本地服务器”向“云原生”转型的剧烈震荡。正如当年 AWS 的崛起让运维工程师（Admin）转型为 SRE，现在的 AI 浪潮正在让编码者转型为意图架构师。</p> <p> 他提到的 AWS 对开源软件的“武器化”（利用开源协议直接推出商业服务）曾引发了 Elastic 与 Redis 等公司的许可协议大战。Mitchell 的观点预示着这种冲突的第二阶段：冲突点不再仅仅是商业利益的分配，而是 <strong>协作契约的失效</strong> 。当 AI 可以模拟人类行为去贡献开源代码时，开源作为一种“社会化生产方式”的根基正在动摇。这种趋势印证了近年来行业内对“主权代码”和“受控生态”的回归。</p> </div> </div> <div id="outline-container-启示与建议" class="outline-3"> <h3 id="启示与建议"> 5. 启示与建议 </h3> <div id="outline-text-启示与建议" class="outline-text-3"> <p>这场对话强化了一个核心假设： <strong>编程的门槛正在消失，但构建稳定系统的门槛正在指数级提高。</strong></p> <div id="outline-container-给不同读者的建议" class="outline-4"> <h4 id="给不同读者的建议"> 给不同读者的建议 </h4> <div id="outline-text-给不同读者的建议" class="outline-text-4"> <ul> <li> <p><strong>对开发者：</strong></p> <ul> <li><strong>改变学习路径：</strong> 不要只练习写逻辑，要练习写“规格说明书（Spec）”和“验证用例”。当你发现 AI 做错时，第一反应应是更新你的 =agents.md=（约束文件），而不是手动修改那几行代码。</li> <li><strong>构建“后台意识”：</strong> 练习在处理高难度思维任务时，将一个低难度的调研任务（如：对比三个库的性能、查找特定协议的边缘案例）外包给 Agent。习惯“并发工作”，而非“线性写码”。</li> </ul> </li> <li> <p><strong>对技术领导者与创始人：</strong></p> <ul> <li><strong>预算权大于技术优劣：</strong> 像 Mitchell 早期反思的那样，企业采购软件不看它是开源还是闭源，而看“谁的预算付钱”。在设计 AI 驱动的 B 端产品时，优先搞清楚你的产品解决的是安全预算、网络预算还是人力预算。</li> <li><strong>重新评估人才背景：</strong> 寻找那些能够长时间进入“深度流（Flow）”且不频繁切换上下文的人。Mitchell 指出，最优秀的工程师往往是那些在社交媒体上“隐身”、工作专注度极高的 9-to-5 职业选手。</li> </ul> </li> <li> <p><strong>对开源维护者：</strong></p> <ul> <li><strong>建立“防御性”准入制：</strong> 即使你的项目目前还小，也要考虑引入自动化检测或人工背书机制，防止被 AI 生成的无效 PR 耗尽精力。</li> </ul> </li> </ul> <p><strong>信号判断：</strong> Mitchell 对 AI 改变编程节奏的观察是 <strong>强信号</strong> ，具有极高的实践价值；而他关于“Git 将在 5 年内消失”的论断更多是基于极端场景的 <strong>合理推断</strong> ，不必急于抛弃现有的版本控制技能。</p> </div> </div> </div> </div> <div id="outline-container-金句摘录" class="outline-3"> <h3 id="金句摘录"> 6. 金句摘录 </h3> <div id="outline-text-金句摘录" class="outline-text-3"> <ul> <li><strong>"AI makes it trivial to create plausible looking but incorrect and low-quality contributions."</strong> （AI 让创造那种看起来像模像样、实则错误且低质量的贡献变得易如反掌。） —— 语境：讨论为什么开源社区必须放弃“默认信任”贡献者的旧习。</li> <li><strong>"Hitting the merge button is the easiest step. It's the years of maintaining whatever you just merged… that's the hard part."</strong> （点击“合并”按钮是最简单的一步。难的是在那之后的数年里，你必须在产品路线图、Bug 修复和客户需求中持续维护你刚才合并的东西。） —— 语境：提醒开发者 fork 一个项目很容易，但接手维护意味着无尽的责任。</li> <li><strong>"Use AI as a way to choose what you think about."</strong> （将 AI 视为一种让你能够自主选择“该思考什么”的工具。） —— 语境：反驳“AI 让人变笨”的论点，主张将平庸的思维过程外包，保留核心创造力。</li> <li><strong>"We are at the 'Gmail moment' for version control."</strong> （我们正处于版本控制系统的“Gmail 时刻”。） —— 语境：预言未来代码管理将不再需要删除分支或清理尝试记录，而是全量存储与语义检索。</li> </ul> </div> </div> <h2> 收听方式 </h2> <ul> <li> 国内：<a href="https://www.xiaoyuzhoufm.com/podcast/60eabfdd030f8753b9982047">小宇宙</a>、<a href="https://emacs.liujiacai.net/cdn-img/emacs/emacstalk-weixin.webp">微信公众号</a>、<a href="https://emacs.liujiacai.net/podcast/index.xml">RSS</a> </li> <li> 国外：<a href="https://podcasters.spotify.com/pod/show/EmacsTalk">Spotify for Podcasters</a>、<a href="https://podcasts.apple.com/podcast/emacstalk/id1574036730">Apple Podcasts</a>、<a href="https://anchor.fm/s/d2d601b4/podcast/rss">RSS</a> </li> </ul> <img src="https://emacs.liujiacai.net/cdn-img/emacs/emacstalk-xyz-qrcode.webp"/> <h2> 反馈 ✉️ </h2><ul><li>对节目有想法或发现内容错误？欢迎来信交流：<a href='mailto:hello@liujiacai.net'>hello@liujiacai.net</a></li></ul>
October 3, 2025
018. Emacs Lisp 三十年“活语言”的实用主义、分裂与现代化之路
<h4>欢迎听众<a href="https://liujiacai.net/donate/">打赏支持</a>，您的支持是我不断创作的动力🍻 </h4> <p> 本期内容是对论文 <a href="https://dl.acm.org/doi/10.1145/3386324">Evolution of Emacs Lisp</a> （<a href="https://egh0bww1.com/posts/2023-05-21-37-tr-evolution-of-emacs-lisp/">中文翻译</a>）的解读和讨论，论文作者包括 Emacs Lisp 的主要贡献者和维护者，<a href="https://www.iro.umontreal.ca/~monnier/">Stefan Monnier</a>、<a href="https://www.deinprogramm.de/sperber/">Michael Sperber</a>。论文回顾了 Emacs Lisp 的历史演变、设计原则、实现细节以及未来发展方向。</p> <p> <figure><img src="https://emacs.liujiacai.net/images/emacs-lisp-mind-map.webp"> </figure> </p> <p> Emacs Lisp 是 Emacs 编辑器的内置编程语言，诞生于 1985 年，由 Richard Stallman 基于 Maclisp 设计。它是一种动态、弱类型、基于列表的解释型语言，具有强大的宏系统和灵活的扩展能力。Emacs Lisp 的设计目标是为 Emacs 提供高度可定制和可扩展的功能，使用户能够根据自己的需求修改和扩展编辑器的行为。</p> <div id="outline-container-headline-1" class="outline-3"> <h3 id="headline-1"> 重要时间节点与功能引入 </h3> <div id="outline-text-headline-1" class="outline-text-3"> <dl> <dt> 1992年 (Emacs 19早期) </dt> <dd>引入文本属性 (Text Properties)。</dd> <dt> 1992年 (Emacs 19) </dt> <dd>advice.el 包引入，提供类似面向切面编程的功能。</dd> <dt> 1994年 (Emacs Lisp 核心) </dt> <dd>引入 Quasiquotation (backquote, unquote, unquote-splicing) 的读取器语法。</dd> <dt> 1995年 (Emacs 19.29) </dt> <dd>改进 Lisp 对象标记方案，增加最大文件和堆大小限制；引入终端本地变量。</dd> <dt> 1998年 (Emacs 20) </dt> <dd>引入 frame-local 变量。</dd> <dt> 2009年 (Emacs 23.1) </dt> <dd>内部采用 Unicode。</dd> <dt> 2012年 (Emacs 24.1) </dt> <dd>引入词法作用域 (Lexical scoping)。</dd> <dt> 2013年 (Emacs 24.3) </dt> <dd>引入 cl-lib（Common Lisp 兼容库）。向量块分配改进性能。采样式 profiler 引入。</dd> <dt> 2014年 (Emacs 24.4) </dt> <dd>引入新的建议机制 nadvice.el。</dd> <dt> 2016年 (Emacs 25.1) </dt> <dd>引入外部函数接口 (FFI) 支持加载 GPL 兼容库。引入 define-inline 宏。</dd> <dt> 2018年 (Emacs 26.1) </dt> <dd>defstruct 使用新的 record 数据类型。</dd> </dl> </div> </div> <div id="outline-container-headline-2" class="outline-3"> <h3 id="headline-2"> 核心语言特性与实现 </h3> <div id="outline-text-headline-2" class="outline-text-3"> <dl> <dt> 动态作用域 (Dynamic Scoping) </dt> <dd>这是 Emacs Lisp 从 MacLisp 继承的关键特性。变量查找在运行时基于调用栈进行。斯托尔曼选择动态作用域是为了满足 Emacs 的可扩展性需求，特别是方便临时修改配置变量（如 default-directory）。尽管 Common Lisp 和 Scheme 已转向词法作用域，Elisp 长期坚持动态作用域。</dd> <dt> Lexical Scoping (词法作用域) </dt> <dd>尽管动态作用域是传统，词法作用域的引入是 Elisp 近年来最重要的变化之一 (Emacs 24.1, 2012)。早期通过 lexical-let 宏实现，但效率和调试不便。词法作用域解决了变量名冲突和闭包创建的问题。然而，由于现有代码对动态作用域的依赖，转换过程并非简单，最终通过选择性地启用词法作用域来解决。</dd> <dt> Lisp-2 </dt> <dd>Emacs Lisp 像 MacLisp 一样，是一个 Lisp-2 语言，函数和普通值的命名空间是分开的。调用绑定到变量的函数需要使用 funcall。</dd> <dt> 符号 (Symbols) 与属性列表 (Property Lists) </dt> <dd>符号是 Emacs Lisp 中表示标识符的数据类型，也常用于表示枚举值。符号还携带一个属性列表，用于存储键值对。</dd> <dt> 数据结构 </dt> <dd> <dl> <dt> Cons Cells 与 Lists </dt> <dd>作为 Lisp 的基础，用于构建单链表，nil 表示列表末尾。</dd> <dt> Structures </dt> <dd>MacLisp 的 defstruct 概念通过 cl.el 包引入，并在 Emacs 26.1 中通过新的 record 数据类型提供更好的支持。</dd> </dl> </dd> <dt> 钩子 (Hooks) 与建议 (Advice) </dt> <dd>钩子是 Elisp 可扩展性的重要机制，允许用户在预定义的点执行额外代码。advice.el (Emacs 19) 和后来的 nadvice.el (Emacs 24.4) 提供了更强大的机制，允许在函数执行之前、之后或围绕其执行代码，即使函数没有预设钩子。尽管斯托尔曼认为 Advice 会使调试复杂，但它非常流行并广泛使用。</dd> </dl> </div> </div> <div id="outline-container-headline-3" class="outline-3"> <h3 id="headline-3"> 实现细节与性能 </h3> <div id="outline-text-headline-3" class="outline-text-3"> <dl> <dt> 字节码解释器 (Byte-Code Interpreter) </dt> <dd>Elisp 代码通常被编译成字节码执行以提高速度。斯托尔曼早期就实现了字节码编译器，“为了速度”。尽管尝试过令牌线程等优化，但字节码解释器的整体性能提升有限。</dd> <dt> 尾递归优化 (Tail-Call Optimization - TCO) </dt> <dd>Elisp 的实现长期缺乏尾递归优化，主要原因在于与动态作用域不兼容。即使在引入词法作用域后，由于现有代码习惯使用迭代，TCO 的实际效益有限，且在解释执行时可能导致问题。</dd> <dt> 数据表示与垃圾回收 (Data Representation and GC) </dt> <dd>Elisp 使用标记方案 (tagging scheme) 来表示不同类型的数据，早期限制了堆和文件大小。随着版本演进，标记方案不断调整以支持更大的内存和文件。垃圾回收 (GC) 早期采用简单的标记-清除算法，主要问题是暂停时间。Emacs 21.1 引入了保守栈扫描 (conservative stack scan) 来改进 GC。XEmacs 保持精确 GC 并进行了多项改进，包括 ephemerons。</dd> <dt> 内存分配 </dt> <dd>为了提高性能，Emacs 24.3 改变了某些对象的分配方式，从直接调用 malloc 改为从“向量块” (vector blocs) 分配，以减少保守栈扫描相关的开销。</dd> <dt> JIT 编译 </dt> <dd>多次尝试为 Elisp 添加 JIT (Just-In-Time) 编译器以提高执行速度，但进展缓慢，主要面临平台支持和优化效果等挑战。</dd> </dl> </div> </div> <h2> 收听方式 </h2> <ul> <li> 国内：<a href="https://www.xiaoyuzhoufm.com/podcast/60eabfdd030f8753b9982047">小宇宙</a>、<a href="https://emacs.liujiacai.net/cdn-img/emacs/emacstalk-weixin.webp">微信公众号</a>、<a href="https://emacs.liujiacai.net/podcast/index.xml">RSS</a> </li> <li> 国外：<a href="https://podcasters.spotify.com/pod/show/EmacsTalk">Spotify for Podcasters</a>、<a href="https://podcasts.apple.com/podcast/emacstalk/id1574036730">Apple Podcasts</a>、<a href="https://anchor.fm/s/d2d601b4/podcast/rss">RSS</a> </li> </ul> <img src="https://emacs.liujiacai.net/cdn-img/emacs/emacstalk-xyz-qrcode.webp"/> <h2> 反馈 ✉️ </h2><ul><li>对节目有想法或发现内容错误？欢迎来信交流：<a href='mailto:hello@liujiacai.net'>hello@liujiacai.net</a></li></ul>
May 21, 2025
017. UNIX：一段历史与回忆
Brian W. Kernighan, computer scientist at Bell Labs and co-founder of Unix, is featured in this episode, which explores the history, design principles, and impact of Unix, offering insights into its development.
19 total episodes available
Recent guests on EmacsTalk
Guests from recent episodes — sign up to see every guest that has ever appeared on this show.
Brian W Kernighan
Guest
Wen Yi
Guest
Elon
Guest
Joyer
Guest
Songpeng Zu
Guest
遥泥 (Yaoni)
Guest
Wang Yong
Guest
Zhang Zepeng
Guest
Guan Yilun
Guest
FENG Shu
Guest
付禹安
Guest
Ling Feng
Guest
Deep-dive analytics for EmacsTalk
Frequently asked questions
Have a different question and can't find the answer you're looking for? Reach out to our support team by sending us an email and we'll get back to you as soon as we can.
- What is EmacsTalk?
- How often does this podcast release new episodes?
This podcast updates daily.
- Where can I listen to this podcast?
This podcast is available on 4 platforms including Apple Podcasts, Spotify, and more. You can also use the RSS feed directly.
- Does this podcast accept guests?
Information about guest appearances is not available.
Legal Disclaimer
Pod Engine is not affiliated with, endorsed by, or officially connected with any of the podcasts displayed on this platform. We operate independently as a podcast discovery and analytics service.
All podcast artwork, thumbnails, and content displayed on this page are the property of their respective owners and are protected by applicable copyright laws. This includes, but is not limited to, podcast cover art, episode artwork, show descriptions, episode titles, transcripts, audio snippets, and any other content originating from the podcast creators or their licensors.
We display this content under fair use principles and/or implied license for the purpose of podcast discovery, information, and commentary. We make no claim of ownership over any podcast content, artwork, or related materials shown on this platform. All trademarks, service marks, and trade names are the property of their respective owners.
While we strive to ensure all content usage is properly authorized, if you are a rights holder and believe your content is being used inappropriately or without proper authorization, please contact us immediately at hey@podengine.ai for prompt review and appropriate action, which may include content removal or proper attribution.
By accessing and using this platform, you acknowledge and agree to respect all applicable copyright laws and intellectual property rights of content owners. Any unauthorized reproduction, distribution, or commercial use of the content displayed on this platform is strictly prohibited.