编程语言与软件工程2020people.inf.ethz.ch
对精简软件的呼吁（1995）
A Plea for Lean Software (1995)
入门 · 约 45 分钟读完前置知识：基本编程经验、对软件工程史的兴趣
导读
这是 Niklaus Wirth 1995 年的一篇短文：他主张软件体积和复杂度的膨胀并非“自然规律”，并以 Project Oberon 为例说明，用少得多的资源也能在更短时间内构建出灵活、强大的系统。文中批评了以“增强用户便利与功能”为由替软件膨胀辩护的说法。
HN 关注点：HN 读者长期争论软件臃肿问题，这篇经典短文被重新贴出，引发关于“精简是否只是审美偏好、大型软件的生产力收益是否更实在”的讨论。
HN 评论精选
这几条评论里：支持 1 质疑 1 补充 2
支持亲历者推崇 Modula-2 的接口/实现分离编译机制，并推荐 Wirth 那本薄而清晰的编译器教材。
这篇文章值得反复贴出，Wirth 的著作也值得每隔几年重读。Oberon 的前身 Modula-2 的模块概念至今无人能及：.def 模块声明接口，可与 .mod 实现分开编译；客户端甚至可以在实现尚不存在时就针对已编译的接口做类型安全的编码。另外，Wirth 的《Compilerbau》（德语，不确定有无译本）清晰得近乎纯净，口袋本才约 100 页，谁读完都会觉得写编译器或字节码解释器很简单，自己也能做。
jll29查看英文原文
It is worth re-posting this, and re-reading Wirth's works every couple of years. The module concept of Oberon's predecessor Modula-2 is still unrivalled today: .def modules that specify the interface and that can be compiled separately from their .mod implementations, which may not even exist when a client application can already be coded against the compiled interface in a type-safe way. Also, Wirth's book Compilerbau (in German, not sure if it was translated) is a piece of pristine clarity; at just ~100 pages in pocket paperback form, everyone reading it immediately feels writing a compiler or byte-code interpreter is simple and they can do it.
补充追问：如果膨胀不是自然规律，那该如何用可观测的证据来定义和检验软件世界的“规律”。
Wirth 说：“通过 Project Oberon 我们已证明，用少得多的资源、比通常更短的时间，也能构建灵活而强大的系统。软件爆炸的瘟疫并不是‘自然规律’。”那么软件世界里什么才算“自然规律”？我们又该如何通过证据去发现它——比如过去 25 年软件膨胀留下的证据？该考察源代码还是可执行代码？用户数量？销售收入？还是源码的结构、可读性、可维护性、可移植性等美学品质，或可执行文件的大小、性能、UI 的直观性？
wombatmobile查看英文原文
"With Project Oberon we have demonstrated that flexible and powerful systems can be built with substantially fewer resources in less time than usual. The plague of software explosion is not a "law of nature." What then, in the software world, is a "law of nature", and how might we discover such a law/s by examining evidence, such as, the evidence deposited over the last 25 years of software proliferation? Might we examine source code, or executable code? Or number of users? Or revenue from sales? Or aesthetic qualities of the source code, such as structure, legibility, or maintainability, or portability; or qualities of the executable code, such as size, performance, or intuitiveness of the UI?
质疑质疑 Wirth 的前提：大型软件的生产力收益真实存在，优化成本最终由消费者承担，性能只是众多特性之一。
我不太认同“增强用户便利与功能被用来为软件体积增长辩护，但细看这些理由站不住脚”这个核心前提。用户仍可以选择 vi、emacs、TextPad 等精简快速的软件，老东西并没有消失。而我的 IDE 会边打字边重新解析代码、立刻报错，我选择更大更“慢”的程序，是因为它让我效率高得多；输入延迟也许不如极简编辑器，但这点代价早已被收益抵消（至少对我如此，各人情况不同）。我能理解对精简程序的美学追求，但忽视容忍大型程序带来的实实在在的生产力收益，我认为是短视的。这在 HN 讨论网页变慢时常被忽略：不只有用户的生产力重要——如果开发者要花两倍时间优化代码去塞进受限内存，那就是同样的功能消费者要付两倍成本（或同样的价格只得到一半功能）。如果速度/性能是客户愿意付钱的功能，他们会告诉你；如果不是，竞争者会靠更多用户真正在意的功能抢走你的市场。
theptip查看英文原文
I don't really buy the core premise that "Enhanced user convenience and functionality supposedly justify the increased size of software, but a closer look reveals these justifications to be shaky". Users can still choose to use vi, or emacs, or textpad, or whatever stripped-down, fast, minimalist software they prefer; the old stuff hasn't gone away. Meanwhile, my IDE re-compiles/re-parses my program as I type, and tells me immediately if there are errors. I choose to use the bigger, "slower" program because it makes me dramatically more productive. Sure, input latency might not be as good as a barebones editor, but that cost more than pays for itself (as always, for me -- YMMV). I can appreciate the aesthetic desire for a lean, minimal program, but to ignore the very real productivity benefits that come from tolerating larger programs is, I think, myopic. This comes up around here a lot in the context of slow web pages; a very important thing to note that I think is often overlooked is that it's not just the user's productivity that matters. If developers have to spend 2x the time optimizing their code to fit in a limited memory allocation, then that's 2x the cost to the consumer for the same amount of features (or 1/2 the features for the same price). If speed/performance is a feature that your customers want to pay for, they will let you know. If it's not, then your competitor will eat your lunch by building more features that users actually care about, while you optimize your existing feature-set. Programs are bounded by "feels slow" on one side, and "expensive to optimize further" on the other. If 99.9% of your users (i.e. the lay users, excluding the experts in the HN crowd) don't perceive your program/page to be slow, why would you optimize further? Sure, if you're Google, a few ms faster can equate to millions of dollars of revenue, but that's not the fitness landscape that most software evolves in.
补充纠正名字拼写：Niklaus 而非 Nikolaus。
他的名字拼作 Niklaus Wirth（不是 Nikolaus），见维基百科。他对软件系统的态度务实而合理。Nikolaus 是另一位名人。
Rochus查看英文原文
> Nikolaus Wirth: A Plea for Lean Software (1995) He spells Niklaus, see https://en.wikipedia.org/wiki/Niklaus_Wirth. And yes, he has a sound, pragmatic attitude towards software systems. Nikolaus is another famous person.
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2020Hacker News 讨论帖163 分 · 137 评
同领域还值得读
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 分钟编辑精选