EmacsTalk

写代码的西瓜
  • 0.0 (0)
  • TECNOLOGÍA
  • CADA MES

EmacsTalk 是一档专注在 Emacs 社区的程序员闲聊节目。M-x thanks-for-listening。官网：https://emacs.liujiacai.net/

  1. 7 MAR

    019. Mitchell Hashimoto 编写代码的新方式

    欢迎听众打赏支持，您的支持是我不断创作的动力🍻 Mitchell Hashimoto Ghostty 是一款快速、功能丰富且跨平台的虚拟终端仿真器，它使用平台原生 UI 和 GPU 加速。 跨国串门儿计划 AI 总结 Mitchell Hashimoto's new way of writing code (2026-02-26, gemini-3-flash-preview) 这是一份基于 Mitchell Hashimoto 近期访谈的深度研报。Mitchell 作为 HashiCorp 的联合创始人，曾主导开发了 Terraform、Vagrant 等改变云基础设施规则的工具。如今他离开管理一线，以独立开发者和观察者的身份，重新定义 AI 时代的编程范式。 1. 导读 在硅谷的叙事中，Mitchell Hashimoto 是一个特殊的坐标：他不仅凭借一己之力推动了“基础设施即代码”（IaC）的普及，更在一个工程师驱动的公司里完成了从开源到商业化的艰难跃迁。如今，当行业普遍迷失在 AI 幻觉与生成式代码的狂潮中时，Mitchell 却回归到了最原始的“手艺人”状态——开发一款极致性能的终端 Ghosty。 这场对话不仅是对 HashiCorp 创业史的回溯，更是一次关于“软件工程尊严”的辩论。Mitchell 在这里揭示了他如何与傲慢的云巨头博弈，为什么他认为 AI 正在摧毁开源社区赖以生存的信任体系，以及他如何通过“始终运行一个 Agent”的策略，在效率巅峰期保持着一种近乎冷酷的清醒。读完你会发现，真正的技术变革，往往发生在人类决定“不把时间浪费在什么地方”的那一刻。 2. 核心观点 Mitchell Hashimoto 的核心世界观可以概括为：*软件工程的本质正从“编写逻辑”转向“意图调度与约束管理”。* 在他看来，AI 带来的不是单纯的效率提升，而是对软件开发生命周期的重构——从代码的版本控制（Git 的局限）到社区的准入机制（开源信任的崩塌），所有基于“人类精力有限”这一假设建立的旧秩序都在失效。他主张开发者应该像管理一支廉价但不可靠的实习生团队一样管理 AI，将重心从“造物”转移到“构建测试支架（Harness）”上。 关键判断 开源社区的“默认信任”模式已经终结。 Mitchell 指出，AI 让制造“看起来像样但低质量（Slop）”的代码成本降为零。过去开源项目通过观察贡献者的“努力程度”来建立信任，而现在 Agent 可以瞬间提交成百上千个 PR。他断言，所有主流开源项目必须转向“默认拒绝（Default Deny）”和“显式背书（Vouching）”的准入系统，否则会被 AI 生成的垃圾信息淹没。 云巨头的性格决定了生态位的生存策略。 基于多年与 AWS、Azure 和 Google Cloud 的博弈，Mitchell 总结了三大巨头的技术文化：AWS 是极其傲慢且具有掠夺性的（时刻准备用原生产品杀死合作伙伴）；Microsoft 则是极其职业且具备共赢思维的（优先问：我们如何共同获利？）；Google 拥有顶尖的技术审美，却在商业感知上几乎完全失明。这一判断解释了为什么 HashiCorp 必须坚持多云策略，因为中立性不仅是技术需求，更是政治生存。 Git 正面临其“Gmail 时刻”。 现有的 Git 工作流（克隆、分支、合并队列）是为人类的产出速度设计的。Mitchell 观察到，在高度 Agent 化的公司中，代码流转速度提升了 10-100 倍，Git 的性能和冲突解决机制在巨大的代码吞吐量面前开始崩溃。他预言版本控制系统需要从“快照记录”转向“全量上下文索引”，不再允许丢弃任何一次尝试。 开发者正进化为“支架工程师（Harness Engineer）”。 Mitchell 提出一个反直觉的习惯：无论是否在写代码，后台始终运行一个 Agent 负责调研或处理琐事。他认为，为了让 Agent 输出高质量结果，开发者 70% 的精力将花在构建“验证环境”和“测试规格书”上。如果 AI 犯了错，不要去修代码，而要去修那个“防止 AI 犯错的支架”。 性能是软件工程中最后的“匠心堡垒”。 在开发 Ghosty 时，Mitchell 执着于将渲染延迟压缩至 10 微秒以内。他承认这在商业上可能“溢出”，但认为在 AI 生成代码泛滥的时代，对底层细节（如 GPU 内存管理、SIMD 指令集）的极致把控，是区分“真正的工程师”与“代码调度员”的唯一标志。 这些观点构成了一个逻辑链条：因为 AI 降低了生产成本（产生垃圾 PR），所以我们必须提高过滤标准（信任背书制）；因为代码生成不再是瓶颈，所以验证代码的正确性（Harness Engineering）和底层运行效率（极致性能）成了新的核心竞争力。 3. 批判与质疑 尽管 Mitchell 的论述极具前瞻性，但其体系中仍存在一些值得考量的盲点。 首先，他提倡的 “显式背书系统（Vouching System）” 虽然能解决 AI 垃圾贡献问题，但极易导致开源社区的 精英阶层固化 。这种类似“Lobsters”社交网站的邀请制，会增加新人入行的隐形门槛，可能扼杀那些非科班出身、缺乏社交资本但有潜力的天才开发者。 其次，他在 AI 工作流中对 “始终运行 Agent” 的依赖，隐含了一个未经验证的前提： 开发者具备极强的任务拆解能力和 Review心理阈值 。普通开发者在面对 Agent 生成的源源不断的代码片段时，极易陷入“决策疲劳”，最终为了追求速度而放弃深度审查。这种“幻觉累积”可能在短期内表现为高产，但在长期维护中会埋下巨大的技术债。 此外，Mitchell 对 Git 衰落 的断言虽然激进且有趣，但忽略了工具链的巨大惯性。Git 不仅仅是技术，更是全球软件工业的“共同协议”。即便它在 Agent 协作中效率低下，更有可能的结果是插件式的补丁（如 Merge Queue 的普及）而非彻底的范式更迭。 4. 行业视野 Mitchell 的分析将我们带入了一个 “后开源时代（Post-Open Source Era）” 。 在行业历史图谱中，这场对话呼应了 2010 年代初从“本地服务器”向“云原生”转型的剧烈震荡。正如当年 AWS 的崛起让运维工程师（Admin）转型为 SRE，现在的 AI 浪潮正在让编码者转型为意图架构师。 他提到的 AWS 对开源软件的“武器化”（利用开源协议直接推出商业服务）曾引发了 Elastic 与 Redis 等公司的许可协议大战。Mitchell 的观点预示着这种冲突的第二阶段：冲突点不再仅仅是商业利益的分配，而是 协作契约的失效 。当 AI 可以模拟人类行为去贡献开源代码时，开源作为一种“社会化生产方式”的根基正在动摇。这种趋势印证了近年来行业内对“主权代码”和“受控生态”的回归。 5. 启示与建议 这场对话强化了一个核心假设： 编程的门槛正在消失，但构建稳定系统的门槛正在指数级提高。 给不同读者的建议 对开发者： 改变学习路径： 不要只练习写逻辑，要练习写“规格说明书（Spec）”和“验证用例”。当你发现 AI 做错时，第一反应应是更新你的 =agents.md=（约束文件），而不是手动修改那几行代码。 构建“后台意识”： 练习在处理高难度思维任务时，将一个低难度的调研任务（如：对比三个库的性能、查找特定协议的边缘案例）外包给 Agent。习惯“并发工作”，而非“线性写码”。 对技术领导者与创始人： 预算权大于技术优劣： 像 Mitchell 早期反思的那样，企业采购软件不看它是开源还是闭源，而看“谁的预算付钱”。在设计 AI 驱动的 B 端产品时，优先搞清楚你的产品解决的是安全预算、网络预算还是人力预算。 重新评估人才背景： 寻找那些能够长时间进入“深度流（Flow）”且不频繁切换上下文的人。Mitchell 指出，最优秀的工程师往往是那些在社交媒体上“隐身”、工作专注度极高的 9-to-5 职业选手。 对开源维护者： 建立“防御性”准入制： 即使你的项目目前还小，也要考虑引入自动化检测或人工背书机制，防止被 AI 生成的无效 PR 耗尽精力。 信号判断： Mitchell 对 AI 改变编程节奏的观察是 强信号 ，具有极高的实践价值；而他关于“Git 将在 5 年内消失”的论断更多是基于极端场景的 合理推断 ，不必急于抛弃现有的版本控制技能。 6. 金句摘录 "AI makes it trivial to create plausible looking but incorrect and low-quality contributions." （AI 让创造那种看起来像模像样、实则错误且低质量的贡献变得易如反掌。） —— 语境：讨论为什么开源社区必须放弃“默认信任”贡献者的旧习。 "Hitting the merge button is the easiest step. It's the years of maintaining whatever you just merged… that's the hard part." （点击“合并”按钮是最简单的一步。难的是在那之后的数年里，你必须在产品路线图、Bug 修复和客户需求中持续维护你刚才合并的东西。） —— 语境：提醒开发者 fork 一个项目很容易，但接手维护意味着无尽的责任。 "Use AI as a way to choose what you think about." （将 AI 视为一种让你能够自主选择“该思考什么”的工具。） —— 语境：反驳“AI 让人变笨”的论点，主张将平庸的思维过程外包，保留核心创造力。 "We are at the 'Gmail moment' for version control." （我们正处于版本控制系统的“Gmail 时刻”。） —— 语境：预言未来代码管理将不再需要删除分支或清理尝试记录，而是全量存储与语义检索。 收听方式

  2. 03/10/2025

    018. Emacs Lisp 三十年“活语言”的实用主义、分裂与现代化之路

    欢迎听众打赏支持，您的支持是我不断创作的动力🍻 本期内容是对论文 Evolution of Emacs Lisp （中文翻译）的解读和讨论，论文作者包括 Emacs Lisp 的主要贡献者和维护者，Stefan Monnier、Michael Sperber。论文回顾了 Emacs Lisp 的历史演变、设计原则、实现细节以及未来发展方向。 Emacs Lisp 是 Emacs 编辑器的内置编程语言，诞生于 1985 年，由 Richard Stallman 基于 Maclisp 设计。它是一种动态、弱类型、基于列表的解释型语言，具有强大的宏系统和灵活的扩展能力。Emacs Lisp 的设计目标是为 Emacs 提供高度可定制和可扩展的功能，使用户能够根据自己的需求修改和扩展编辑器的行为。 重要时间节点与功能引入 1992年 (Emacs 19早期) 引入文本属性 (Text Properties)。 1992年 (Emacs 19) advice.el 包引入，提供类似面向切面编程的功能。 1994年 (Emacs Lisp 核心) 引入 Quasiquotation (backquote, unquote, unquote-splicing) 的读取器语法。 1995年 (Emacs 19.29) 改进 Lisp 对象标记方案，增加最大文件和堆大小限制；引入终端本地变量。 1998年 (Emacs 20) 引入 frame-local 变量。 2009年 (Emacs 23.1) 内部采用 Unicode。 2012年 (Emacs 24.1) 引入词法作用域 (Lexical scoping)。 2013年 (Emacs 24.3) 引入 cl-lib（Common Lisp 兼容库）。向量块分配改进性能。采样式 profiler 引入。 2014年 (Emacs 24.4) 引入新的建议机制 nadvice.el。 2016年 (Emacs 25.1) 引入外部函数接口 (FFI) 支持加载 GPL 兼容库。引入 define-inline 宏。 2018年 (Emacs 26.1) defstruct 使用新的 record 数据类型。 核心语言特性与实现 动态作用域 (Dynamic Scoping) 这是 Emacs Lisp 从 MacLisp 继承的关键特性。变量查找在运行时基于调用栈进行。斯托尔曼选择动态作用域是为了满足 Emacs 的可扩展性需求，特别是方便临时修改配置变量（如 default-directory）。尽管 Common Lisp 和 Scheme 已转向词法作用域，Elisp 长期坚持动态作用域。 Lexical Scoping (词法作用域) 尽管动态作用域是传统，词法作用域的引入是 Elisp 近年来最重要的变化之一 (Emacs 24.1, 2012)。早期通过 lexical-let 宏实现，但效率和调试不便。词法作用域解决了变量名冲突和闭包创建的问题。然而，由于现有代码对动态作用域的依赖，转换过程并非简单，最终通过选择性地启用词法作用域来解决。 Lisp-2 Emacs Lisp 像 MacLisp 一样，是一个 Lisp-2 语言，函数和普通值的命名空间是分开的。调用绑定到变量的函数需要使用 funcall。 符号 (Symbols) 与属性列表 (Property Lists) 符号是 Emacs Lisp 中表示标识符的数据类型，也常用于表示枚举值。符号还携带一个属性列表，用于存储键值对。 数据结构 Cons Cells 与 Lists 作为 Lisp 的基础，用于构建单链表，nil 表示列表末尾。 Structures MacLisp 的 defstruct 概念通过 cl.el 包引入，并在 Emacs 26.1 中通过新的 record 数据类型提供更好的支持。 钩子 (Hooks) 与建议 (Advice) 钩子是 Elisp 可扩展性的重要机制，允许用户在预定义的点执行额外代码。advice.el (Emacs 19) 和后来的 nadvice.el (Emacs 24.4) 提供了更强大的机制，允许在函数执行之前、之后或围绕其执行代码，即使函数没有预设钩子。尽管斯托尔曼认为 Advice 会使调试复杂，但它非常流行并广泛使用。 实现细节与性能 字节码解释器 (Byte-Code Interpreter) Elisp 代码通常被编译成字节码执行以提高速度。斯托尔曼早期就实现了字节码编译器，“为了速度”。尽管尝试过令牌线程等优化，但字节码解释器的整体性能提升有限。 尾递归优化 (Tail-Call Optimization - TCO) Elisp 的实现长期缺乏尾递归优化，主要原因在于与动态作用域不兼容。即使在引入词法作用域后，由于现有代码习惯使用迭代，TCO 的实际效益有限，且在解释执行时可能导致问题。 数据表示与垃圾回收 (Data Representation and GC) Elisp 使用标记方案 (tagging scheme) 来表示不同类型的数据，早期限制了堆和文件大小。随着版本演进，标记方案不断调整以支持更大的内存和文件。垃圾回收 (GC) 早期采用简单的标记-清除算法，主要问题是暂停时间。Emacs 21.1 引入了保守栈扫描 (conservative stack scan) 来改进 GC。XEmacs 保持精确 GC 并进行了多项改进，包括 ephemerons。 内存分配 为了提高性能，Emacs 24.3 改变了某些对象的分配方式，从直接调用 malloc 改为从“向量块” (vector blocs) 分配，以减少保守栈扫描相关的开销。 JIT 编译 多次尝试为 Elisp 添加 JIT (Just-In-Time) 编译器以提高执行速度，但进展缓慢，主要面临平台支持和优化效果等挑战。 收听方式 国内：小宇宙、微信公众号、RSS 国外：Spotify for Podcasters、Apple Podcasts、RSS 反馈 ✉️ 对节目有想法或发现内容错误？欢迎来信交流：hello@liujiacai.net

  3. 21/05/2025

    017. UNIX：一段历史与回忆

    欢迎听众打赏支持，您的支持是我不断创作的动力🍻 本期节目来介绍一本书：Unix: A History and a Memoir（PDF 下载地址，访问码：emacstalk），作者是贝尔实验室的计算机科学家 Brian W. Kernighan，他是 Unix 的联合创始人之一，也是 C 语言、AWK 的主要开发者之一。书中详细回顾了 Unix 的发展历程、设计理念和对计算机科学的影响。 比较特别的是，本期节目没有嘉宾，是由西瓜和 NotebookLM 协同完成！NotebookLM 是一个基于 LLM 的笔记应用，支持 Markdown 和 LaTeX 语法，具有强大的搜索和组织功能。它可以帮助你更高效地管理和利用你的知识，建议大家都去试试。 如果你对以后的节目有任何建议或者想法，欢迎给我留言，让我们一起把节目做得更好！ 时间线 02:15 生成播客节目：探索UNIX历史的奇妙之旅 04:16 软件开发的演变：从 Multics 到 UNIX 的故事 06:19 软件开发过程中的挑战与经验教训：重写项目的利与弊 08:22 如何减少失败率？探讨重生计划前阅读UNIX历史的重要性 10:24 深入探索UNIX诞生背后的秘密武器：贝尔实验室的创新之道 12:24 探索与创新的天堂：贝尔实验室与UNIX的诞生 14:25 成功的秘诀：自由探索的氛围、密切的合作和知识分享 16:26 从PDP到UNIX：一个被低估的操作系统的诞生历程 18:26 追寻历史的足迹：贝尔实验室与UNIX的诞生 1. Unix 是如何诞生的，最初的目的是什么？ Unix 的诞生源于贝尔实验室的一个小团队，最初由 Ken Thompson 和 Dennis Ritchie 等人开发。它的起源可以追溯到 Multics 项目，当贝尔实验室退出 Multics 后，Thompson 在一台 PDP-7 计算机上开始了 Unix 的原型开发。最初，这个系统是为了给一个文件系统实现提供测试平台，以便于加载数据进行吞吐量等方面的测试。Ken Thompson 在他的伴侣 Bonnie 回娘家期间，意识到他距离一个分时系统只差一个 exec 调用、一个 shell、一个编辑器和一个汇编器，并决定用三个星期的时间完成它们。因此，最初的 Unix 系统是一个单用户系统，随后才扩展为多用户。名称“Unix”源于对“Multics”的戏称，“UNICS”（UNiplexed Information and Computing Service），最终演变为 Unix。 2. Unix 文件系统有何特点和创新之处？ Unix 文件系统的一个核心特点是其层次结构，以一个根目录 / 为起点，形成树状结构。目录本身也被视为文件，其内容由系统维护，包含关于文件和子目录的信息。每个目录都有特殊的条目： "." 指代自身，".." 指代父目录。这种结构使得通过从根目录开始的路径名（例如 /usr/bwk/book/book.txt）可以轻松访问任何文件。文件系统还支持当前目录的概念，允许使用相对路径。 Unix 的另一个重要创新是将外围设备（如磁盘、终端等）表示为文件系统中的文件。这意味着可以使用与访问普通文件相同的系统调用（如 open, read, write, close）来访问这些设备，极大地简化了编程。此外，文件权限控制机制也相对简单但有效，使用 9 个比特位分别控制文件所有者、所属组和其他用户的读、写、执行权限，后来还引入了 setuid 位以允许普通用户以文件所有者的权限执行程序。 3. Shell 在 Unix 系统中扮演什么角色？ Shell 是 Unix 系统中用户与操作系统交互的主要接口。它是一个普通的用户程序，负责解释用户输入的命令并执行相应的程序。用户通过 shell 输入命令，shell 执行这些命令并在完成后等待下一个输入。Shell 并非操作系统内核的组成部分，这使得用户可以根据需要选择或编写不同的 shell 程序，提供了极大的灵活性。 Shell 的一个重要功能是支持 I/O 重定向和管道（pipes）。I/O 重定向允许将命令的输入或输出连接到文件，而管道（用 | 字符表示）则允许将一个命令的输出直接作为另一个命令的输入，实现多个程序的串联执行，极大地提高了命令组合的能力。例如， ls | wc 命令将 ls 命令的输出（每行一个文件）传递给 wc 命令进行行数统计，从而计算目录中的文件数量。 4. C 语言与 Unix 的关系是什么？ C 语言与 Unix 系统有着紧密的联系，两者可以说是共同演进、互相成就。在 PDP-11 计算机上开发 Unix 时，由于之前的 B 语言不适合字节寻址的 PDP-11，Dennis Ritchie 开始改进 B 语言并为其编写编译器，最终诞生了 C 语言（最初称为 NB，New B）。 C 语言支持与 PDP-11 硬件数据类型相匹配的数据类型（如字节、整数、浮点数），并提供了强大的指针操作能力，这使得它非常适合用于系统级编程，包括编写操作系统本身。Unix 的大部分代码都用 C 语言编写，而 C 语言的许多特性也受到 Unix 开发经验的影响。两者共同构成了 Unix 系统及其开发环境的基础。 5. Yacc、Lex 和 Make 这些工具在 Unix 开发中有什么作用？ Yacc (Yet Another Compiler-Compiler)、Lex (Lexical Analyzer generator) 和 Make 是 Unix 环境中重要的开发工具，它们都遵循模式-动作（pattern-action）范式，用于简化程序开发过程。 Yacc 是一个编译器-编译器，用于根据语言的语法规则生成解析器程序。它接受语言的语法定义和与之相关的语义动作，并生成一个 C 语言程序，该程序能够解析输入并执行对应的语义动作。Yacc 极大地简化了编写编译器和其他需要解析输入语言的程序的过程。 Lex 是一个词法分析器生成器，与 Yacc 配合使用。它根据正则表达式模式识别输入中的“词法单元”（如保留字、变量名、运算符等），并生成一个 C 语言程序，该程序能够从输入流中提取这些词法单元。 Make 是一个构建自动化工具，用于管理多文件程序的编译和链接过程。它读取一个描述文件依赖关系的配置文件，根据文件的修改时间确定需要重新编译和链接哪些文件，并只执行必要的步骤，以保证最终程序是最新的。Make 极大地提高了开发效率，特别是在大型项目中。 这些工具通过自动化语言处理和构建过程中的重复任务，为 Unix 开发环境提供了强大的支持，并至今仍在广泛使用。 6. Unix 是如何从一个研究项目走向商业化和广泛应用的？ Unix 最初在贝尔实验室内部使用，用于支持专利申请等工作，后来开始向大学授权（通常是第六版），收费 nominal。由于 AT&T 不提供商业支持，大学用户被迫自行维护和改进系统，这促进了用户群体的形成和 Usenix 等用户组织的出现，分享经验和代码。 大学授权（尤其是加州大学伯克利分校的 BSD 版本）和用户社区的活跃 contributed 到 Unix 的传播和发展。然而，AT&T 后期试图将 Unix 商业化，成立了 USL (Unix System Laboratories) 并发布了 SVR4 等版本。商业化过程带来了商标问题（UNIX™）和“Unix Wars”等争议，不同版本的 Unix 在市场上竞争。 尽管商业化过程中存在波折，Unix 的核心思想和技术（如文件系统、shell、管道、工具集等）影响深远。最终，独立开发的类 Unix 系统（如 Minix 和 Linux）的出现，摆脱了商业限制，并在开源社区的推动下获得了巨大的成功，成为现代计算基础设施的重要组成部分。 7. Unix 的主要技术遗产有哪些？ Unix 的技术遗产是巨大的，它引入了许多至今仍然影响着计算机科学和软件工程的概念和实践： 文件系统：简单的层次结构、将设备视为文件以及灵活的权限控制。 Shell 和命令行工具：强大的命令行接口、I/O 重定向和管道，以及大量功能单一但可以组合使用的工具（如 grep, sed, awk 等），体现了“小工具，大用途”的理念。 C 语言：一种强大的、适合系统级编程的通用语言，成为后续许多语言的基础。 开发工具：Yacc, Lex, Make 等自动化工具，简化了程序开发和构建过程。 模式-动作范式：在 grep, sed, awk, Make, Yacc, Lex 等工具中广泛应用，提供了一种强大的数据处理和程序生成方式。 可移植性：随着时间的推移，Unix 逐渐实现了跨硬件平台的 portability，打破了硬件锁定。 这些技术遗产不仅体现在 Unix 的各种后代系统（如 Linux, macOS, BSD 等）中，也 deeply 影响了其他操作系统的设计和软件开发的实践。 8. Unix 的成功是否可能被复制，未来技术发展的趋势是什么？ 关于 Unix 的成功是否可以复制，这是一个复杂的问题。书中提到，伟大的想法通常来自个人。Ken Thompson 和 Dennis Ritchie 等少数核心开发者的贡献是 Unix 早期成功的关键。他们的技术洞察力和创造力， coupled with 贝尔实验室宽松的研究环境，促成了 Unix 的诞生和早期发展。 然而，复制这种成功是困难的。当今的软件开发环境更加复杂，竞争激烈。但书的作者仍然对未来持乐观态度，认为伟大的想法仍将来自个人。关于未来的技术发展趋势，虽然书中没有给出明确预测，但可以 inferred 的是，对简单、强大工具的需求仍然存在，模式-动作范式和领域特定语言（little languages）等思想可能在新的应用领域继续发挥作用。同时，开源社区在推动软件发展方面的重要性也日益凸显，这与 Unix 早期在大学和用户群体中的传播模式有相似之处。 Unix 开发主要事件时间线 1956年:

  4. 14/12/2024

    016. 文一的开源项目学习之路

    欢迎听众打赏支持，您的支持是我不断创作的动力🍻 大家好，这是 2024 年的第一期节目，首先给大家说声抱歉！其中一个原因是没有特合适的人，所以希望大家推荐想在节目上看到的嘉宾，我来勾搭！ 本期节目的嘉宾是文一，这位零零后在校大学生是一名开源项目的积极参与者，目前是开放原子开源基金会 “内核一周一审” 负责人，有 IvorySQL，PikiwiDB 内核代码贡献经验。参与节目专门制作了一个 PPT，感兴趣的听众可以下载阅读，地址：Emacs 编辑器对于我的启发与帮助。 通过和他深入交谈，我们发现他是一个富有思考深度和总结能力的年轻人。在学习和参与开源项目的过程中，他不仅收获了丰富的经验，还踩过不少“宝贵”的坑，帮助大家来少走弯路。 在本期节目中，文一将分享他独特的视角和宝贵经验：如何在众多开源项目中精准识别那些用心打造的优质项目？如何提高 Emacs 开箱即用的体验，扩大 Emacs 用户基数？ 时间线 00:02:03 嘉宾自我介绍 00:06:22 Emacs 使用工作流介绍 00:18:32 如何用 Emacs 阅读大型项目 00:33:08 学习 PostgreSQL 经历 00:57:02 未来规划 链接 Bulma， 基于Flexbox的免费、开源、现代化的CSS框架，并且使用Sass进行构建， 它100%响应式，全部模块化，并且完全免费 Symfony, High Performance PHP Framework for Web Development 【咨询】转向LSP-BRIDGE以后，如何阅读大型项目的源代码？ - Emacs-general - Emacs China abo-abo/org-download: Drag and drop images to Emacs org-mode PikiwiDB(Pika)，为海量数据存储设计的高可用键值数据库 Hello from 走向内核 | 走向内核 收听方式 国内：小宇宙、微信公众号、RSS 国外：Spotify for Podcasters、Apple Podcasts、RSS 反馈 ✉️ 对节目有想法或发现内容错误？欢迎来信交流：hello@liujiacai.net

  5. 19/08/2023

    015. 漫谈 Vim，对 Bram Moolenaar 的致敬

    欢迎听众打赏支持，您的支持是我不断创作的动力🍻 Vim 作者 Bram Moolenaar 不幸在 2023-08-03 去世，本期节目是对 Bram 的致敬，Long Live Vim！ 嘉宾 Elon：GitHub、Blog Elon 领蜂（Joyer）：GitHub Joyer 时间线 00:00:15 开场，嘉宾介绍 00:03:00 Vim 的历史由来 00:09:29 编辑器之战，按键方式、启动速度、扩展语言 00:28:05 Vimscript vs Emacs Lisp 00:38:52 NeoVim 诞生的原因 00:54:56 资助乌干达贫困儿童的由来 01:04:10 Bram 对年轻程序员的建议 01:09:03 对未来编辑器的畅想 Vim 诞生历史 1969 年，Ken Thompson 为 Unix 开发 ed Unix 之父：Ken Thompson & Dennis Ritchie 1975 年，George Coulouris 改进了 ed，得益于显示技术的进步，增加 inline edit，他命名为 em，editor for mortals（凡人的编辑器）。 1976 年，Bill Joy 在 em 的基础上继续尽快扩展，增加了两个 mode： Open mode，像 em 一样按行就地修改， Visual mode，可以全屏编辑文件（和我们现在的方式类似） Joy 称之为 ex（extended ed），并在 1978 年在 BSD 的首次版本中内置，在次年的 BSD 第二版中改名为 vi，表示默认以 visual 方式打开 ex。在 Vi 中，首次引入 : 作为命令的前缀，比如 :wq 表示保存并退出。 Joy 开发 Vi 时的键盘：Lear Siegler ADM-3A 由于 Vi 衍生于 ed，版权在 AT&T 那里，不方便修改，因此社区开始出现各种开源版本的 Vi，1988 年 Bram 创建了 Vi Imitation，但是没有开源出来，1991-11-02 首次对外发布， 1993 年发布的 2.0 版本，包括多级撤销和针对编译器错误的快速修复模式（multi-level undo and a “quickfix” mode for compiler errors），正式改名为 Vi IMproved 链接 How to get started with the ed text editor Where Vim Came From Bill Joy's greatest gift to man – the vi editor A Look at Vim, a Text Editor for the Ages 编辑器之战 对 Bram 去世的悼念文章 Message from the family of Bram Moolenaar Bram Moolenaar has died | Hacker News Vim Boss 即将发布的 9.1 将会专门纪念 Bram，就像 9.0 专门纪念 Sven Guckes The Legacy of Bram Moolenaar Vim creator Bram Moolenaar dies aged 62 • The Register Bram Moolenaar, Author of the Open Source Vim Code Editor, Has Died 重复性劳损 Repetitive Strain Injury [PATCH] Asynchronous functions (settimeout, setinterval, and cancelinterval) Why Neovim? with TJ DeVries, Neovim core maintainer (Changelog Interviews #457) Why we 💚 Vim (Changelog Interviews #450) |> Changelog 如无必要，勿增实体，即“简单有效原理” Bram 在 2022 的采访：Bram Moolenaar: "Vim is a very important part of my life." 收听方式 国内：小宇宙、微信公众号、RSS 国外：Spotify for Podcasters、Apple Podcasts、RSS 反馈 ✉️ 对节目有想法或发现内容错误？欢迎来信交流：hello@liujiacai.net

    1 h 24 min

  6. 14/01/2023

    014. 生物信息学博士后 Songpeng 的打怪升级之旅

    欢迎听众打赏支持，您的支持是我不断创作的动力🍻 好久不见，由于主播最近半年琐事较多，因此更新有所停滞，不过好饭不怕晚、良缘不怕迟，本期迎来了另一位重磅嘉宾：生物信息学博士后 Songpeng Zu，目前居住在美国，使用 Emacs 大概七年左右。 嘉宾使用 Emacs 的方式是典型的实用主义，把 Emacs 打造成了提升工作效率的利器，主播也希望 Emacs 用户不要过早走上 All in Emacs 的“极端”道路。 在高考阴差阳错进入生物专业后，为了便于找工作，研究生阶段转到了更切近实践的生物信息学，但学术之旅 并不是一帆风顺，经历了在学术圈与工业界的反复踌躇，相信嘉宾的这段经历对很多正在面临类似选择的朋友会有所启发，也祝 Songpeng 在学术之路上走出自己的风采，过程与结果一样重要。 温馨提示：本期节目时间近 2 小时，听众可以按时间线选择收听 本期人物 主播：西瓜 | Twitter 嘉宾：Songpeng Zu（beyondpie）| 博客 | Emacs 配置 时间线 🎧 00:00:48 自我介绍 00:02:00 接触 Emacs 动机 00:04:00 生物信息学介绍 00:11:46 入门 Emacs 过程 00:22:17 Emacs Lisp 学习经历 00:28:02 日常工作流介绍 01:03:46 职业经历介绍 01:17:04 新年职业规划 01:31:47 好物分享 Show Notes 📖 一年成为Emacs高手 (像神一样使用编辑器) purcell/emacs.d: An Emacs configuration bundle with batteries included noctuid/general.el: More convenient key definitions in emacs cofi/evil-leader: key for evil emacs-evil/evil-collection: A set of keybindings for evil-mode 如何处理 evil 快捷键与第三方包的冲突 noctuid/evil-guide: Draft of a guide for using emacs with evil meow-edit/meow: Yet another modal editing on Emacs / 猫态编辑 AlphaFold Protein Structure Database Emacs 内置的 Vi 仿真包：vip-mode Emacs 邮件客户端：Gnus Newsreader Helm | Emacs incremental completion and selection narrowing framework joaotavora/eglot: A client for Language Server Protocol servers Overleaf, Online LaTeX Editor Emacs 首次发布时间是 1976，截至到 2023 年，已经有 47 年历史 寻找 GitHub 的替代品 - Keep Coding github/dev: Press the . key on any repo Peer pressure - Wikipedia 浪潮之巅（第四版）（上下册），豆瓣评分：9.1 好物分享 Modern Operating Systems， 豆瓣评分：9.1 macos - Why can I use Emacs shortcuts in many OS X programs? - Ask Different 收听方式 国内：小宇宙、微信公众号、RSS 国外：Spotify for Podcasters、Apple Podcasts、RSS 反馈 ✉️ 对节目有想法或发现内容错误？欢迎来信交流：hello@liujiacai.net

    1 h 50 min

  7. 25/06/2022

    013. 遥泥的澳洲生活与 Emacs 经验分享

    欢迎听众打赏支持，您的支持是我不断创作的动力🍻 本期嘉宾是一位半路出家的码农，目前居住在澳大利亚，职位是数据工程师，使用 Emacs 大概三年。 本期节目主要分为两大部分，第一部分是嘉宾的 Emacs 接触过程，会聊到初学者学习 Emacs 的常见问题，二八定律；第二部分会介绍澳大利亚的衣食住行，是开阔眼界的好机会。 温馨提示：本期节目部分内容声音过小，请听众包涵。 本期人物 主播：西瓜 | Twitter 嘉宾：遥泥（Yaoni）| 博客、LinkedIn | 本科经济专业；研究生半年翻译，后转到计算机 时间线 🎧 00:00:53 自我介绍 00:03:30 接触 Emacs 的过程 00:12:15 Emacs 对嘉宾的吸引点 00:24:55 EmacsLisp 学习经历 00:33:10 使用 org 进行文学编程 00:36:26 选择澳大利亚的原因 00:46:04 澳大利亚生活分享 01:12:44 好物分享 Show Notes 📖 嘉宾 Emacs 配置 Sacha Chua ∑ Xah Code Org-roam CloverDX | Solve demanding, real-world data challenges Literate Programming with Org-mode 澳洲读研年费用（2017年） 翻译：20w 计算机：30w 四大 (会计师事务所) - 维基百科 分享 哈佛大学公开课：幸福课-网易公开课 收听方式 国内：小宇宙、微信公众号、RSS 国外：Spotify for Podcasters、Apple Podcasts、RSS 反馈 ✉️ 对节目有想法或发现内容错误？欢迎来信交流：hello@liujiacai.net

  8. 05/04/2022

    012. 前 Deepin CTO 王勇的 Emacs 传奇经历

    欢迎听众打赏支持，您的支持是我不断创作的动力🍻 本期嘉宾可能是国内 Emacs 社区最资深的用户：王勇（常用 ID： manateelazycat，懒猫）。使用 Emacs 有 15 年之久，创造了 400 多个插件（独立插件包 30 多个），光是这两个数字就足以证明其硬核程度。让听众想不到的是，嘉宾接触 Emacs 的动机竟然是“戒游戏瘾”，且在接触 Emacs 一年左右就达到融会贯通的状态，经过多年深耕，最终达到与 Emacs 心流（身心）合一的境界。对于嘉宾来说，Emacs 已不再只是生产力工具，更像一个老友，默默陪伴在嘉宾身边。近两个小时的内容，精彩不容错过。 本期人物 主播：西瓜 | Twitter 嘉宾：王勇 | GitHub | Emacs China 账户 时间线 00:00:54 嘉宾自我介绍 00:02:49 Emacs 初印象 00:16:36 什么样的人适合 Emacs 00:26:00 谈自由软件 00:31:03 写的 400 个插件中，印象最深的 00:31:03 开源项目维护的心得体会 00:44:40 使用 Emacs 十五年心得体会 00:54:46 EmacsOS？EAF 的诞生 01:37:20 嘉宾近况 01:41:47 推荐 Show Notes 经历总结：我人生的前28年 对 Emacs 新手的建议：读 ELisp 手册 对嘉宾影响比较大的插件 项目重构： color-moccur.el，嘉宾后来写了 color-rg，解决了它大目录搜索慢的问题 括号补全：paredit，嘉宾后来基于 tree-sitter 写了 grammatical-edit。前者基于正则匹配，后者基于语法分析 纯文本浏览器：emacs-w3m，与 EWW 类似 Cairo - The relationship between libraries: Clutter, Cogl, Clutter, GTK+, etc 嘉宾使用 Haskell 重新造的一个 Emacs：Manatee 推荐： 罗大伦博士：每天聊点《道德经》 推荐大家多学不同的编程语言，每学一种编程语言就会增加一种看世界的不同角度，学得编程语言多了，自身能力会更强，心态也会更加包容 喜欢的三个人，这三个人的经历一直激励着我 Richard Stallman：世界上现存的顶尖黑客，虽然很多时候都很极端，但是RMS老人家在计算机哲学上有很多深入的思考 John Carmark（约翰·卡马克）：美国的电玩游戏程序员、id Software的创始人之一。主要作品：Quake（雷神之锤）、Doom（毁灭战士）。最敬佩他的学习能力和动手能力，有啥困难直接去解决，不给自己设限制 王守仁（字号：字伯安，号阳明子）：人生最低落的时候看他的书明白了，至善至真，只要内心活洒脱了活明白了，人生的很多事情自然就顺了 与懒猫一起工作：欢迎加入我们，我们继续折腾 Linux 懒猫生活照 收听方式 国内：小宇宙、微信公众号、RSS 国外：Spotify for Podcasters、Apple Podcasts、RSS 反馈 ✉️ 对节目有想法或发现内容错误？欢迎来信交流：hello@liujiacai.net

Ver todo (19)

Acerca de

EmacsTalk 是一档专注在 Emacs 社区的程序员闲聊节目。M-x thanks-for-listening。官网：https://emacs.liujiacai.net/

Información

  • Creador
    写代码的西瓜
  • Años de actividad
    2021 - 2026
  • Episodios
    19
  • Clasificación
    Apto
  • Copyright
    Copyright © 2021 - 2024 Jiacai Liu
  • Mostrar sitio web
    EmacsTalk

También te podría interesar