编程与软件工程nhplace.com
Common Lisp：不为人知的故事
Common Lisp: The Untold Story
2012 — 2019，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
Kent Pitman 从亲历者视角讲述 Common Lisp 如何从多个 Lisp 方言与实现中走向标准化，以及 ANSI 委员会过程中的分歧、妥协和版权等问题。这不是语言教程，而是标准制定史和“Lisp Wars”的一手记录。
为什么经久不衰：它把技术标准背后的政治、人物与偶然性讲得具体可感，对理解语言设计和标准化过程至今仍有启发。
HN 评论精选
参与标准化即使不是核心人物也能影响结果，追问歧义和早期实现都可能左右最终决定。
好文章。起初我只觉得这是配咖啡的晨读，但它确实让我反思自己参与标准和委员会的经历。一个很大的收获是：如果你对某个主题感兴趣并参与进去，就能以意想不到的方式影响它。我的名字没出现在什么重要规范上，但其中有些想法或建议来自我——不是因为我多重要或多聪明，而是因为我参与了，所以能影响和帮助决策。哪怕只是追问一处歧义，也可能产生意想不到的影响：有次我问某句话该怎么理解，结果发现一半人认为是这样，另一半人认为正相反。后来澄清了，但要是没人问，那会是多大的烂摊子！
sophacles查看英文原文
Great article. At first I thought "What a nice read for my morning coffee". But it certainly has gotten me thinking about my own experience with standards and committees and working groups. I should note now, I've never been a big player in any of these, but have participated - so my experiences are a bit different than Kent Pitman's, but related. I think a big takeaway from this should be: if you are interested in a subject and get involved, you can influence it in unexpected ways. My name is not on any major specs or standards, but some of my ideas or suggestions are there. Not because I am all that important or super smart, but because I was involved and therefore able to influence and help decisions. Simple things like asking questions about ambiguity can have unexpected influence. One time I asked a question about a line and it turned out half the people involved thought it was one way, and the other half thought the opposite. Clarification ensued, but what a mess it would have been if no one had asked! Another thing that I find to be a useful lesson in this article is that sometimes the dog wags the tail, and sometimes the tail wags the dog. Frequently you see people on committees arguing over some detail that matters, but not as much as you might think. Frequently the decision comes down to someone just implementing it one way in a pre-release. Those implementations will become either a great example of why the other option is better, or of why the choice taken is better (or at least that the choice wasn't that big of a deal after all). Committees take on a life of their own, and exist in a bit of echo chamber, so sometimes scoping of issues gets disproportionately wrong. A final personal observation that doesn't come through in this article, but I think is important. If you do research or cutting edge work, just hanging out at these types of meetings provides tons of fodder for exploration and research. Ideas are usually just floating through the air in the form of "if $THING works we could $X, but if it doesn't we would have to $Y". Every time you hear that, there is a paper to be written. Other times you hear great ideas for companies - "The $PROBLEM is a major source of concern", but it turns out $PROBLEM isn't really a problem, it has been solved in a different corner of the world nicely. Porting $SOLUTION from one domain to another is a starting path to profitable companies. There is a downside though, is that there is a bit of self-hyping that needs to be done in these processes. If you have been paying attention, writing papers, doing exploration, sometimes your contribution gets lost into the general idea space. People will start talking about the concepts of your work as if they came from nowhere. This isn't intentional, ideas seem to have a life of their own like this, but if you wrote a paper, and someone is now touting the concept as something that just came to them (even in changed form), you need to gently point them at your work, so you can get some credit. Basically it's personal branding, and a bit uncouth, but necessary unfortunately.
质疑 Lisp 实现差异为何不能靠宏或移植层来消除。
我一直没搞清 Lisp 各实现到底差在哪里。语法这么简单，似乎不是语法问题，那就只剩内建函数和库了。内建函数总可以模拟，库也可以移植。那为什么不存在某个宏（Lisp 程序员总爱吹宏）能把针对一套内建和库写的代码转换成另一套？
rogerbinns查看英文原文
What has never been clear to me about Lisp is how these implementations differ. The syntax is so simple it doesn't seem to be that, so that would leave builtins and libraries. Surely builtins can be emulated and libraries can be ported. So why doesn't there exist some macro (Lispers always brag about them) that could transmogrify code written for one set of builtins and libraries to another?
ANSI 规范的版权归属轶事是文章亮点。
文章里有一段很有意思，是 6.2 节“ANSI and Copyright”，作者讲述了一通涉及规范版权归谁所有的电话。值得一读。
angersock查看英文原文
There is an interesting bit (section 6.2, "ANSI and Copyright") in which the author relates a phonecall that involved the copyright issue for who owns a spec. It's an interesting read.
老用户从 InterLisp-D 转向 Common Lisp 的复杂感受，以及长期坚持使用 CL。
能听到“Lisp Wars”的内部视角很有意思。当时作为外人，我的感受是失望。我很喜欢 Xerox 1108 Lisp Machine 上的 InterLisp-D。不过 Xerox 也提供了 Common Lisp 实现，仍保留了很棒的 UI，而且我记得还支持 DWIM。如今我已有约 35 年频繁使用 Common Lisp 的经验，最新项目/产品也是用 Common Lisp 写的。
mark_l_watson查看英文原文
Interesting to hear an insiders perspective of the ‘Lisp Wars’. My outsider’s perspective, at the time, was disappointment. I really liked InterLisp-D on my Xerox 1108 Lisp Machine. That said, Xerox provided a Common Lisp implementation that still had the UI wonderfulness and I think they still supported DWIM. I now have about 35 years of frequent Common Lisp use/experience, and my latest project/product is written in Common Lisp (http://kgcreator.com).
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选