编程与软件工程norvig.com编辑精选
Lisp：Java 的替代方案（2000）
Lisp as an alternative to Java (2000)
2012 — 2021，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
Peter Norvig 的经典页面：他分别用 Java 和 Lisp 实现同一个程序，比较编写耗时、代码长度和注释量，结论是 Lisp 写得更快、代码更短。文中也回应了常见的反驳（JVM 性能、冗长是否更易读），并附上两种实现的代码供读者自行判断。
为什么经久不衰：它把一个模糊的争论——“哪种语言更有生产力”——变成了可以量化、可以复现的具体实验，而它牵出的表达力、可读性、工具生态等问题二十多年后依然没有定论。
HN 评论精选
评估语言的维度选错了：冗长、JVM 慢、编写慢都不是关键，可读性和持续演进才重要，Python 的成功也印证了这点。
我认为 Java 给我们的教训是：我们开发者当年评估语言时用错了维度。Java 太啰嗦！（但啰嗦能减少注释需求，而注释随软件演进常常误导人；2014 年的 Java 8 更是大幅改变了局面。）Java 因为 JVM 跑得慢！（但 JVM 不断演进，所有 Java 程序都免费获得升级；何况我现在有主频数 GHz 的处理器。）Java 写起来更费时！（但第一次写程序从来不是难点，真正重要的是软件的持续演进。Norvig 的代码是很漂亮的 Lisp，但密度太高，需要的解释性注释比实际功能还多，功能并不自明。当然你也能写出同样毛病的 Java 代码，但我觉得写出可读的 Java 比写出可读的 Lisp 更容易。我认为 Python 的成功进一步印证了这一点。
mabbo查看英文原文
I think the lesson to learn from Java was that we, developers, were evaluating languages on the wrong parameters. Java is too verbose! (But that can reduce the need for so many comments, and comments can often mislead as software changes. Also, Java 8 was 2014 and it changed the game massively.) Java runs slowly because of the JVM! (But the JVM evolves and improves, giving free upgrades to all Java programs over time. Also, I have a multi-GHZ processor now.) Java takes longer to write! (But the first time you write a program is never the hard part- it's continuous evolution of software that matters.) Norvig's code is beautiful and very good Lisp. But it's so dense that it requires more lines of explanatory comments than actual functionality. The code's functionality isn't self-evident. And sure, you can write Java code that has the same flaws, but I find it's easier to write readable Java code than it is to write readable Lisp. I think Python's success is further evidence of this perspective.
文档应区分“对外 API 是什么”和“内部如何维护”；多团队的大型系统更契合 Java 的工程化路线。
原话说“按专业人士的方式写代码，就意味着要写注释”。如果这是一个“专业”的组件或服务，今天多数情况下他大概会把文档分成两类：提交的接口/API 的“是什么”，以及内部维护的“怎么做”。比如 print-translations 的 docstring 就把两者混在了一起。顺带一提，到 2000 年时 Java 已经用 Javadoc 强调可复用的 API 文档好几年了；而 Emacs 这类 Lisp 环境早了几十年就在 IDE 超文本里展示 docstring，至今仍非常适合单枪匹马的 Lisp 高手。企业开发、SaaS、微服务、多团队的大型系统，恐怕更适合走 Java 那种更偏软件工程的方向。
neilv查看英文原文
> the directions said to code as you would professionally, and that means I should comment my work. Were this a "professional" component/service, in perhaps the majority of situations today, he'd probably separate his docs into two kinds of documentation: the committed interface/API what, and the internal maintenance how. The docstring for `print-translations`, for example, conflate these two kinds. Incidentally, by 2000, Java had emphasized reuse API documentation for a few years, with how it presented Javadoc for both the core Java API and layered development, from the start. By contrast, Lisp environments that exposed docstrings in IDE hypertext, like Emacs did, did some doc things better than Java for decades before, and are still really well-suited to army-of-one genetically-enhanced supersoldier Lisp hackers. Enterprise development, SaaSes, microservices, large systems with multiple teams, etc., were arguably better off heading in the more software engineering direction that Java was going. (Which is not to say that Lisps can't do the what&how docs separation. I've done a few embedded API docs things for Scheme and Racket that initially were inspired by Javadoc, Perl, and some of the less-commonly-used embedded docs setups for other languages. And have worked on a couple large Lisp systems that arguably wouldn't have been possible in a language without some of the Lisp family's other still-unusual strengths, nor without the highly-skilled developers that Lisps seem to attract disproportionately.)
Clojure 单点编码效率高，但生态偏企业化、缺少共享基础代码，算上架构思考时间整体项目并不更快。
我作为独立开发者用 Clojure 大约两年了，生产力确实有提升，感觉做下一件事所需的时间在递减（像 O(log n)？）。但 Clojure 仍是相当企业化的生态，参与者不像 Python 生态那样分享基础代码；参与者也都很有经验，所以我得自己坐下来读代码、为整个项目做架构决策。把这些思考时间算进去，一个 Clojure“项目”（而不是一段代码）的耗时肯定比 Python 或 Java 更多。
demonshreder查看英文原文
I have been using Clojure as a solo developer for about two years now, there is definitely a productivity increase. It always feels like the amount of time required to do the next thing is incrementally decreasing (like Ologn?) While all that is fun, Clojure is still a very enterprise ecosystem, where participants don't share as much elementary code as in Python ecosystem. Participants are also quite experienced, thus I have to sit, read through and make architectural decisions for the entirety of the project. When we add this thinking time into the measurement, the time taken for a Clojure 'project' (not a piece of code) is definitely more than Python or Java (IMO).
Lisp 的短板不在语言本身，而在缺少开箱即用的一流 IDE，Emacs 的入门门槛劝退了新手。
Lisp 是很棒的语言，对 Web 开发尤其出色，大家真该在这个领域给它一个机会。QuickLisp 用起来是种享受，语言可移植性强、规范优秀、编译器一流。我认为拖后腿的是缺少一流的 IDE。我在 Emacs 上经历了一年的爱恨交织，如今能把它用得很顺，但说实话，有时我就想要一个精致、开箱即用、点几下就能用的免费 IDE。Portacle 是正确方向上的一步，但依赖 Emacs 让这门语言更小众、在争夺初学者时吃亏。如果有大公司能把 Sublime、SLIME、paredit 和 Emacs 的部分可定制性结合起来，Common Lisp 或许会火起来。
abhinav22查看英文原文
Lisp is a wonderful language (Common Lisp in particular, but I am dabbling in Scheme now too), and absolutely fantastic for web development - seriously people should give it a chance in that space, I would totally develop any SPA in Lisp[1]. QuickLisp is simply a joy to use, and the language is very portable with a fantastic specification and many top notch compilers. IMO, what holds it back is a lack of a top notch IDE. It took me a year of love & hate with Emacs, I can now make pretty good use of the amazing software that is Emacs (where everything can be changed), but honestly at times I want a simple point & click free IDE which is polished and does most things well and out of the box. Portacle is a step in the right direction, but the Emacs dependency IMO does make the language a bit more niche and lose out to other languages for beginners. If some big corporation can mix sublime with slime with paredit with some of the customize ability of Emacs, then Common Lisp could explode in popularity. Don’t get me wrong - I LOVE Emacs and everything about Emacs & CL combined, but it took me a year to get to this point. [1] For those interested, I wrote this article covering the basics: https://ashok-khanna.medium.com/lisp-the-web-4c00c88d11f9
历次讨论
同类还值得读
开源应用架构
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编辑精选