编程语言与软件工程2014cr.yp.to
对精简软件的呼吁（1995）
A plea for lean software (1995)
入门 · 约 15 分钟读完前置知识：软件工程常识、编程语言基础
导读
这是 Niklaus Wirth 1995 年的一篇短文，呼吁开发“精简软件”：反对不必要的复杂性和膨胀，主张以更小、更简单、更可理解的设计来构建系统。文中结合 Oberon 等实践，讨论语言与系统设计中的删繁就简，并把可理解性视为软件质量的一部分。
HN 关注点：软件膨胀与复杂度问题，讨论焦点是极简软件哲学是否现实、现代软件为何越来越臃肿，以及 Wirth 本人至今仍在删代码的实践。
HN 评论精选
这几条评论里：支持 1 质疑 1 补充 1 亲历 1
补充Wirth 到 2018 年仍在为简化而删代码、删优化，身体力行 lean software。
令人惊讶的是，Niklaus Wirth 至今仍在从 Oberon 中删除代码：20180720 - 更新编译器：ORP.Mod.txt 和 ORG.Mod.txt。全局变量基址的缓存“curSB”已从 ORG.Mod 中移除。移除这项优化让编译器更简单。
dchest查看英文原文
Amazingly, Niklaus Wirth still removes code from Oberon: 20180720 - Update compiler: ORP.Mod.txt and ORG.Mod.txt Cash for base adr of global variables "curSB" has been removed from ORG.Mod. Removal of this optimization makes compiler simpler. https://www.inf.ethz.ch/personal/wirth/news.txt
支持引用 Wirth 式原则：系统应能被单个人完整理解，否则不该建。
一个如果无法被单个人完整理解——或至少理解到相当细节程度——的系统，大概就不应该被建造。
clarkevans查看英文原文
A system that is not understood in its entirety, or at least to a significant degree of detail by a single individual, should probably not be built.
亲历雇主让员工保持忙碌的激励会促使开发者给成熟软件加无谓功能，从而毁掉好产品。
我认为导致软件臃肿、被毁掉的一个因素被漏掉了……我不知道总体上有多普遍，但我亲眼见过它毁掉好几个很好的产品。那就是雇主希望员工保持忙碌。如果一个软件达到了极高质量，维护它的开发者仍然得每周填满 40 小时（很可能更多）来取悦老板。于是他们只能做唯一能做的事——毁掉产品。这也是我认为软件工程师在某些情况下应该拿保留聘用的原因之一。对特定产品的领域知识非常有价值，而公司常常忽视这一点。他们会把工程师调去某个更新的项目，留下更初级的人维护原项目——而这个初级的人总得找事填满时间。这除了让那个以控制多少员工、控制多大规模来定义自我价值的短视经理受益外，对谁都没好处。
otakucode查看英文原文
I think one factor that leads to bloated, ruined software was missed... I don't know how common it is overall, but I have personally seen it ruin several very good products. And that is the simple fact that employers want their employees to remain busy. If a piece of software reaches a point of exceptional quality - the developers working on it still have to fill 40 (likely more) hours a week to appease bosses. And so they do the only thing available - they ruin the product. This is one of the reasons that I think software engineers should, in certain cases, work on retainer. Domain knowledge of a specific product is very valuable, and companies routinely ignore this. They will shuffle an engineer off to some newer project and leave a more junior person to handle maintenance of the original project - and that junior person will have to fill their time somehow. This serves no one except for the shortsighted manager who determines their self worth by how many and how much they control their employees.
质疑以 Joel Spolsky 的“市场总投给臃肿软件”作反方：精简理想难敌市场现实。
反方观点：http://www.joelonsoftware.com/articles/fog0000000020.html 或者他后来一篇博客里的金句：“不管这让你们这些洁癖多难受，市场总是投票给 bloatware。”我希望他错了；智能手机 512MB 内存现在算低端让我很困扰。但我想我们只能接受这个行业现实。
mwcampbell查看英文原文
Counterpoint: http://www.joelonsoftware.com/articles/fog0000000020.html Or this soundbite from a later blog entry of his: "No matter how much it bothers you neat freaks, the market always votes for bloatware." I wish he were wrong; it bothers me that 512 MB is now considered low-end for RAM in a smartphone. But I guess we just have to accept this reality of our industry.
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2014Hacker News 讨论帖38 分 · 12 评
- 2018Hacker News 讨论帖133 分 · 100 评
同领域还值得读
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 分钟编辑精选