编程语言与软件工程2018iro.umontreal.ca
Emacs Lisp 的演化
Evolution of Emacs Lisp
入门 · 约 60 分钟读完前置知识：Emacs 使用经验、Lisp 基础
导读
这篇论文系统回顾了 Emacs Lisp 从 1985 年至今的演化历程，涵盖语言设计、实现机制（如 GC、字节码编译）以及近年新增特性（如 bignum 支持）。附录还包含对 Lucid Emacs 分裂关键人物 Joseph Arceneaux 的独家访谈，首次呈现了 FSF/Lucid 分裂中他的视角。
HN 关注点：Emacs 是 HN 读者心中的传奇软件，Elisp 的语言演化史和 FSF/Lucid Emacs 分裂的口述历史引发了浓厚兴趣。
HN 评论精选
这几条评论里：支持 1 质疑 1 补充 2
支持盛赞 Elisp 及论文对语言新特性的介绍
Elisp 太棒了！正是凭借这门优秀的扩展语言，Emacs 才成为真正的集成开发环境。论文很好地概述了语言过去和最新的发展，比如 bignum 支持（7.3 节）就是最令人兴奋的新特性之一。
triska查看英文原文
Elisp is awesome! Emacs is truly an integrated development environment also thanks to this great extension language. This paper provides a nice overview of past and also very recent language developments. For example, support for bignums (Section 7.3) is one of the most exciting new features. Thank you very much for putting this together, and for all your work on Emacs!
补充推荐附录访谈：首次披露 Lucid Emacs 分裂中 Arceneaux 的视角
对 Emacs 开发的人文历史感兴趣的人一定要看附录 B「Joseph Arceneaux 访谈」。关于 FSF/Lucid Emacs 分裂已有许多叙述，但这是第一次听到他这一方的说法——据他所知他是唯一同时为 FSF 和 Lucid 工作过的人。在当年 jwz 整理的邮件链中，身处漩涡中心的 Arceneaux 只留下一封恳求的信：双方的历史叙述都有失准确，希望大家放下分歧重新合作，社区才会受益。
nickdrozd查看英文原文
For those interested in the human aspects of Emacs development, be sure to check out Appendix B, "INTERVIEW WITH JOSEPH ARCENEAUX". Many accounts have been given of the FSF / Lucid Emacs "schism", but I think this is the first time that his side of the story has been told. His perspective is unique in that he was the only person AFAIK to have worked for both FSF and Lucid. [1] shows the full email chain history surrounding the schism, along with Jamie Zawinski's hilarious but partisan introduction. Arceneaux contributed just one plaintive email: > As the person somewhat in the middle this extended phlegm, it strikes me that both accounts of this history contain a certain degree of inaccuracy. > Be that as it may, I would like to urge the parties involved to forget all this and again make efforts to join forces. Lucid has some talented hackers which can and have done good things for emacs (in fact, version 19 already uses some of their code), and if the "bosses" can work out their politics, the community will benefit. [1] https://www.jwz.org/doc/lemacs.html
质疑肯定其史料价值，但认为论文偏重实现机制而非编辑器模型与文化的演变
Emacs 是我的编辑器，我热爱它，但对它是否实现尾递归、lambda 是否用宏实现并不感兴趣。这篇文章堪称 Emacs 传说的经典之作，但和我期待的不同：我本想读到的是「编辑器模型」层面的演变——扩展如何与系统交互、文化如何变迁——而本文记录的是模型背后的实现机制。这对档案式记录很有价值，但若花一晚研究机制，我宁愿去读 JVM，它比 Elisp 解释器更强大有趣。
roenxi查看英文原文
Emacs is my text editor, I love it to bits but I don't have much interest in whether it implements tail call recursion or if lambdas are implemented as a macro. So while the article is a great bit of work, quite praiseworthy and possibly an instant classic of Emacs lore I'm going to be critical of it because I was hoping for something different. Emacs the system is a programming environment that is used to create a model of what a text editor should look like (in Elisp), then an implementation of that model with windows and suchlike (in Elisp, C and with a bit more thrown in for good measure). Extensions build on that model to accomplish magic of various forms. I was anticipating an interesting read on competing ideas of what that model should look like, and how extensions customarily interacted with it, and how the culture has changed over time. 1985 was not the high point for string manipulation and I expect there has been a lot of change through the 90s and 00s, let alone the 10s. This document is a record of the mechanisms behind the Emacs model. Important to record, a great service for the archivists who really will care, but if I'm going to invest an evening learning about mechanism I'd rather read up on the JVM which is frankly more powerful and interesting than the Elisp interpretor. Elisp is a historical curiosity to be sure and probably interesting diversion to anyone implementing a lisp (who really should be looking to Common Lisps or Clojures of the world for most of the inspiration), but it this document isn't selling the interesting points of the story which is how it was being used. If I'm reading about Emacs generators the only reason I can think of that they are relevant to an Emacs user in in 2020 is in context of what the implications of that are for how Emacs models documents and a text editor.
补充调侃 GC 停顿问题靠删掉提示消息「解决」的趣闻
论文提到：早期用户对 mark&sweep GC 的主要抱怨是 GC 停顿，而 Emacs 19.31 的「解决方案」非常简单——直接移除显示 GC 进行中的提示消息，此后关于 GC 性能的抱怨就很少了。我敢打赌在 300 波特率的终端上，显示这些消息比 GC 本身还耗时。
DonHopkins查看英文原文
>During the early years of Emacs, the main complaints from users about the simple mark&sweep algorithm were the GC pauses. These were solved very simply in Emacs 19.31 by removing the messages that indicated when GC was in progress. Since then complaints about the performance of the GC have been rare. Most of them have to do with the amount of time wasted in the GC during initialization phases, where a lot of data is allocated without generating much garbage. At 300 baud, I bet the GC messages took longer to display than the GC itself.
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2018Hacker News 讨论帖194 分 · 55 评
- 2020Hacker News 讨论帖140 分 · 15 评
同领域还值得读
Google 的软件工程（2017）
Software Engineering at Google (2017)
介绍了 Google 的软件工程实践，包括其单一代码库（monorepo）、几乎全部开发在主干进行而非分支、代码审查、构建系统 Blaze、协议缓冲区等工具与流程，并讨论了频繁重…
编程语言与软件工程2017 · 1,127 分 · 465 评 · 引用 15入门 · 约 45 分钟编辑精选Peter Naur：编程作为理论构建 (1985)
Peter Naur – Programming as Theory Building (1985)
Peter Naur 1985 年的经典论文《Programming as Theory Building》提出：编程的本质不是写代码或文档，而是在程序员头脑中构建对程序及其运行…
编程语言与软件工程2016 · 629 分 · 74 评入门 · 约 45 分钟编辑精选SciPy 1.0：Python 科学计算的基础算法
SciPy 1.0: fundamental algorithms for scientific computing in Python
这篇发表于 Nature Methods 的论文介绍了 SciPy 1.0——Python 科学计算生态的基石库，涵盖其核心算法模块（优化、积分、插值、线性代数等）、软件架构与社…
编程语言与软件工程2020 · 387 分 · 98 评入门 · 约 45 分钟编辑精选Lisp 的历史（1979）
History of Lisp (1979)
这是 Lisp 发明者 John McCarthy 于 1979 年为 HOPL（编程语言史）会议撰写的回顾文章，讲述 Lisp 的起源、设计动机与早期演进，文中也涉及 if 表…
编程语言与软件工程2018 · 352 分 · 44 评入门 · 约 45 分钟编辑精选使用 NumPy 进行数组编程
Array Programming with NumPy
这篇 Nature 文章介绍 NumPy 的数组编程模型及其在科学计算中的核心作用：以 ndarray 为中心，通过向量化操作让 Python 高效处理多维数组。
编程语言与软件工程2020 · 318 分 · 134 评入门 · 约 40 分钟编辑精选