编程与软件工程winestockwebdesign.com
Lisp 的诅咒
The Lisp Curse
2011 — 2022，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
《Lisp 之祸》是一篇探讨 Lisp 强大表达能力带来悖论的经典文章：Lisp 太灵活，以至于在其他语言中属于技术问题的事情，在 Lisp 社区里变成了社会问题——人人都能造轮子，导致生态碎片化、难以形成合力。文章多年来反复引发关于 Lisp 为何未能流行的讨论。
为什么经久不衰：它提出了一个关于语言设计、社区文化与生态碎片化的深刻命题，每次重读都能引发对'强大是否等于成功'的反思，至今仍是编程语言讨论的经典参照。
HN 评论精选
Lisp 不流行最可能只是因为缺少有能量的发起者，而非技术原因
奥卡姆剃刀提示：没有一种 Lisp 方言像表达力更弱的语言那样流行，原因可能只是还没人造出来。语言曾经是规范，如今是开源项目，而开源项目的成败更多取决于发起者的能量。大型语言项目发起者屈指可数，且没人恰好选择了实现 Lisp 方言。这种状况会一直成立直到被打破——比如 Clojure 就可能是反例。次可能的原因则很平常：主流程序员被 s-表达式劝退了。
pg查看英文原文
Occam's Razor suggests that the reason there is no dialect of Lisp as popular as less expressive languages is that no one happens to have created one yet. What languages are has changed. Languages used to be specs. Now they're open source projects. Open source projects seem to succeed based more on the energy of their initial organizers than anything else. There are only a few big language-project organizers, and none of them happens to have chosen to implement a language that is a dialect of Lisp. That's the sort of thing that's true until it's false. E.g. Clojure could be the counterexample. Maybe there's more to it than a small sample size, but that seems the likeliest explanation. The second most likely explanation is almost as mundane: that the reason new dialects of Lisp have trouble attracting adherents is that mainstream programmers are put off by s-expressions.
与其争论 Lisp 的地位，不如把精力用于实际写软件
整篇文章可以浓缩为其中一句话：'Lisp 太强大，以至于其他语言中的技术问题在 Lisp 中成了社会问题。'文章不错，但我对这类讨论 Lisp 伟大之处及其现状的文章已经审美疲劳。希望这些精力花在写出优秀软件上。别再把 Lisp 当宗教，把它当作创造美好事物的伟大工具。
TY查看英文原文
Most of the essay can summarized by this quote from it: Lisp is so powerful that problems which are technical issues in other programming languages are social issues in Lisp. While this is not a bad essay I'm experiencing a fatigue from reading articles/books/posts about great powers of Lisp and why Lisp is where it is today. Instead, I'd love to see that mental energy spent on advocacy/defence/adulation/hatred of various Lisp dialects on actually writing great software. Let's stop looking at Lisp as a religion and instead use it as a great tool to create beautiful things. Disclaimer: I've used CL, Scheme and Clojure on my various (mostly personal) projects. For the current one, I use Python as it fits better for what I'm doing today. My next project will use whatever it needs to work.
'因太强而不成功'的论证站不住脚，易用性才是流行关键
我总是警惕'我们没成功是因为我们太强了'这类论证。Ruby 也极易扩展，甚至有人抱怨它太容易写 DSL 以致人人都有自己的不兼容语言，可 Ruby 却成功了。凭什么 Ruby 比 SML 市场份额大？可能就是大多数人觉得它更易用。至于 Qi 的类型推断引擎是图灵完备、一人写成——Haskell 功能众多，把它的实验性特性都移植到 Qi 同样需要团队，没有什么 Lisp 特性能让这容易几个数量级。
luu查看英文原文
I’m always wary of arguments along the lines of “we weren’t successful because we were too awesome”, when there are alternative explanations. Could there possibly be any other reason? I’ve found Ruby to be very easy to extend, and one complaint I’ve heard is that it’s so easy to write DSLs that everyone has their own incompatible languages. And yet, Ruby is successful. So, how come Ruby is more marketshare than, say, SML? Could it possibly be that most people just find it easier? It implements most of the unique features of Haskell and OCaml. In some respects, Qi surpasses them. For instance, Qi's type inferencing engine is Turing complete. In a world where teams of talented academics were needed to write Haskell, one man, Dr. Tarver wrote Qi all by his lonesome. Seriously? Qi is nice, and “better” than Haskell and Ocaml in some respects, but it’s also inferior in many other respects. To port all of Haskell's experimental features to Qi would require teams of people. There's nothing particular to Lisp that would make that orders of magnitude easier. Haskell just has a lot of features.
Clojure 的出现让 Lisp 布道之争变得毫无意义
当年写 Common Lisp 时我读这类文章会很在意，甚至参与语言布道之争。如今我毫不在意——只管写出能用的好应用。部分代码跑在 JVM 上，部分跑在浏览器里，还能共享三个生态（Clojure/ClojureScript、Java、JavaScript）的丰富库。对我来说，Clojure 在短短几年内就让这类文章彻底过时了。
jwr查看英文原文
I used to read these kinds of articles with interest, back in my Common Lisp programming days. They would worry me. Back in the day, I would even sometimes participate in language advocacy discussions. These days, I don't care at all — I just write great apps that work (fast). Some code runs on the JVM, some code runs in the browser, some runs in both places. I get to use an impressive set of libraries from at least three different ecosystems (Clojure/ClojureScript, Java, Javascript). I get to use fantastic languages with impressive concurrency support. I deliver applications which customers pay money for. For me at least, Clojure made this kind of writing totally obsolete, in the span of several years.
历次讨论
同类还值得读
开源应用架构
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编辑精选