编程与软件工程steve-yegge.blogspot.com
Lisp 不是可接受的 Lisp（2006）
Steve Yegge: Lisp is not an acceptable Lisp. (2006)
2009 — 2013，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
Steve Yegge 在 2006 年发表的这篇争议性文章认为，Lisp 虽然强大，却不是一个“合格的”主流语言：它缺少统一的社区共识、没有统一的实现和明确的演进方向，卫生宏缺失，CLOS 等标准扩展各自为政。他主张只有出现类似 Python/Ruby 那样的“独裁者”和共识社区，Lisp 才可能大规模成功。文章引来 Lisp 实践者的激烈反驳，也因准确预测了 Arc 被 Clojure 取代而为人津津乐道。
为什么经久不衰：这是一篇标志性的语言论战文章：关于 Lisp 的可扩展性、宏、社区治理和主流化困境的讨论至今仍在 Clojure 等方言的社区复现，评论也提供了 Lisp 实践者视角的平衡声音。
HN 评论精选
Lisp 实践者反驳：可扩展性正是 Lisp 的本质，Yegge 对 CLOS 的描述有事实错误，Lisp 不需要为了流行而改变。
仍然是 Yegge 的风格：肤浅且大多是错的。真正使用 Lisp 的人（而不是只写 Lisp 文章的人）根本不觉得标准之外有扩展是个问题。Lisp 的全部意义就在于它能以多种方式被轻易扩展：可编程的编程语言。这当然带来一堆麻烦，但这正是它、也正是人们使用它的原因。他关于 CLOS 的叙述大多是错的：CLOS 不是一堆宏，而是一个三层架构——核心用 CLOS 自身面向对象地写成，上面是函数式接口，再上面是一堆方便用户定义类、泛函、方法等语言对象的宏。宏不是问题，是特性；卫生宏很好但并非必需，它们不需要重新设计。Lisp 永远不会大规模成功（对许多用户来说太复杂、太动态、太强大），强行改造它去追求大众成功毫无意义。
lispm查看英文原文
it is still Yegge: shallow and mostly wrong. People who actually use Lisp (opposed to people who only write about it) have no problem that there are extensions to the standard. The whole point of Lisp is that it is easily extended in many ways: the programmable programming language. Sure it brings a bunch of problems, but that's what it is and why people use it. The stuff he writes about CLOS is mostly wrong. CLOS is not implemented as a bunch of macros. CLOS is actually a three level architecture: the core is written object-oriented in CLOS itself, on top is a functional interface and for user convenience there is a bunch of macros for easy definition of classes, generic functions, methods and some other language objects. Then, macros are no problem. They are a feature. No, 'hygienic' is fine, but not needed. No they don't need to be rethought. They do a useful job like they are. No, Lisp will never be massively successful (because it is a bit too complicated, too dynamic, too powerful for many users) and bending the language trying to make it 'massively successful' won't improve anything. No, I don't want a dictator. Lisp has choice, various alternatives and a more democratic approach. Lisp is still a good choice for computing with symbols. If you don't need that, then you might not need Lisp. But that's not a reason that Lisp should change. Should a helicopter be changed in design because someone does not use it, but drives a car? Should the helicopter be changed, because more people drive cars, getting a drivers license for cars is easier than getting a pilot's license for helicopters? Lisp is different, for a reason and this difference will ensure its survival for many years. We have now fifty years that the basic ideas have proven to be useful and I don't see that this will change in the coming years.
Lisp 不是单一语言，家族内部差异巨大；真正独特的只是语法和用户可扩展的后期绑定编译规则。
我一直很困扰于我们计算机科学家用词的不精确。Lisp 不像 Python 或 Java 那样是一门语言——PLT Scheme 和 elisp 之间的差距，比 Python 和 Java 之间大得多。Lisp 系语言真正独特（其实也并没有那么难理解）的地方只有语法，以及编译规则采用后期绑定：编译器是留给用户扩展的。大致上说，你本来就应该能说“unless (...) 会翻译成 if (!...)”。其余的设计决策并不那么离经叛道：文本照样被解析，然后被解释或编译成机器码执行。
andreyf查看英文原文
It's always bothered me how imprecise we are with words as computer scientists. Lisp is not a language in the sense that Python or Java is. PLT Scheme is much (much!) farther from elisp in feature sets than Python is from Java. The only thing unique to Lispy languages (and really not at all that hard to understand) is the language syntax and the way the compilation rules are late-bound. That is, the compiler is intended to be extended by the user. Roughly, you're intended to be able to say "unless (...)" will translate to "if (!...)". The rest of the design decisions made aren't even that outlandish: you still have text which is parsed and either interpreted or compiled into machine code, which is run. More foreign (and interesting), I think, is the research being done at Alan Kay's lab now: http://piumarta.com/software/cola/
Yegge 预测 Clojure 会抢先取代迟迟不出的 Arc，事实证明他说对了。
“我的预测：有人会等得不耐烦，在 Arc 发布之前就把它‘Torvalds 化’成过时之物。”Rich Hickey 用 Clojure 做的差不多就是这样。所以这个预测相当准确。
jimbokun查看英文原文
"My prediction: someone will get tired of waiting, and they'll Torvalds Arc into obsolescence before it's ever released." This is what Rich Hickey did with Clojure, more or less. So this was a pretty accurate prediction.
资深 Lisp 者指出 Yegge 列出的问题多是理论问题，在真实项目中并不构成实际痛点。
别错过文章评论里 Pascal Costanza 从资深 Lisp 人角度给出的意见，有助于摆正视角：“我的印象是，你既没有长期使用 Common Lisp 也没有用过 Scheme，更没有在规模可观的项目里用过。你提到的大多数问题都是‘学术性’的——理论上存在，实践中却很少困扰到你。”
felideon查看英文原文
Don't miss Pascal Costanza's opinion in the comments, to put things in perspective from an expert Lisper: My impression is that you [haven't used] neither Common Lisp nor Scheme on a regular basis, and/or in a considerably sized software project. Most of the issues that you mention are "academic", in the sense that they are theoretical problems which tend not to bite you in practice
历次讨论
同类还值得读
开源应用架构
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编辑精选