编程语言与软件工程2015worrydream.com编辑精选
No Silver Bullet（1986）
No Silver Bullet (1986)
入门 · 约 45 分钟读完前置知识：软件工程基础、编程经验
导读
这是 Fred Brooks 1986 年的经典论文《没有银弹》。他区分了软件的“本质复杂性”（问题本身固有的）与“偶然复杂性”（工具带来的），并断言没有任何单一技术或方法能在十年内让软件开发效率提升一个数量级，因为最困难的部分在于精确确定要构建什么，而非编写代码本身。
HN 关注点：这是软件工程史上最具争议和影响力的论文之一，HN 读者持续争论其“本质/偶然复杂性”论断在今天（尤其是 AI 时代）是否仍然成立。
后来怎么样
软件工程领域最著名的论断之一，'没有银弹'成为业界广泛引用的经典概念，引发了关于软件本质复杂性的持续争论及多篇反驳文章（如 Mannaert 等人的回应），至今仍是软件工程教学中的必读文献。
HN 评论精选
这几条评论里：支持 2 质疑 1 补充 2
支持推荐将反驳论文核心论点作为思维练习
经典好文，我把它布置给学生阅读。一个很有价值的练习是尝试反驳他关于“本质复杂性”与“偶然复杂性”的核心论点——你最后可能会发现自己并不同意他！但正因如此我才喜欢这篇文章：无论赞同与否，它都能促使你思考。
chillpenguin查看英文原文
Great paper, a classic. I assigned this as reading to my students. A worthwhile exercise is to try to refute the core idea regarding "essential" vs "accidental" complexity. You may find you end up disagreeing with him! But that is why I like this paper so much. Agree or disagree, it makes you think, and it's worth thinking about.
质疑认为如今偶然复杂性激增，消除后仍可能数量级提升
四年前我写过一篇相关短文。要点是：Brooks 写作时是对的，但此后偶然复杂性大幅增加，如果认识到并消除它，如今实现一个数量级的改进是可能的。
DonaldFisk查看英文原文
I wrote a short essay on this four years ago, here: http://www.fmjlang.co.uk/blog/NoSilverBullet.html The gist of it is that although Brooks was correct when he wrote No Silver Bullet, since then there's been an enormous increase in accidental complexity and, if that is recognized and removed, an order of magnitude improvement is now possible.
支持赞其预见性，认为机器学习可能是未来的潜在例外
这篇文章极具预见性。Brooks 大胆预测三十年后软件仍由程序员坐在编辑器前逐行敲出处理各种场景的代码，且产出大多糟糕，因为状态空间近乎无限——这种复杂性无法被抽象掉。Web、语言和工具都只是生活质量改善，并未“解决”软件固有的复杂性。唯一可能挑战“没有银弹”定律的是机器学习，虽然现在还不是。
aedron查看英文原文
The essay is remarkably prescient. Brooks dared to predict that thirty years later, software would still be created by programmers sitting in front of editors, painstakingly typing up code branches for all of the scenarios a given program is supposed to handle. And their output would still mostly suck, because of the infinity of possible states, mostly due to variables and synchronicity. Complexity that cannot be abstracted away. Given how starry-eyed we usually are about even the near future, that is bold. The web, language advances, tooling - these are quality-of-life improvements. They don't 'solve' the inherent complexity of software development, the way it was promised by CASE tools (Brooks' likely target with his essay) and countless other 'business oriented' approaches. In fact those approaches have failed so many times that they have been largely abandoned, so in recent times, Brooks' essay might seem superfluous. The one advance that might finally challenge the 'no silver bullet' rule is machine learning. Not yet, given that it is still an esoteric tool for a specialized class of problems, as part of traditional software systems. But with increasing computing power, I can imagine a future where machine learning can be set to work on broader tasks and start to look like magic self-directed software development.
补充工具进步不降低难度，但大幅提升小团队产能
这让我想起骑行界的一句话：骑行不会变轻松，你只是骑得更快了。软件也是如此——框架和库越来越好，工作并没有变容易，但过去需要三十人做的事，现在三个人就能完成。看看 Django 或 Rails 对比用 C 和 cgi-bin 从零搭建就知道了。
msandford查看英文原文
This kind of thing reminds me of a phrase from cycling: It never gets easier, you just go faster. I feel like that's absolutely how software is. As we have better frameworks and libraries and everything the job doesn't get easier. But what happens is that it's now possible to do something with a team of three that might have taken thirty before. Just look at Python/django or Ruby/Rails vs doing all that yourself with C and cgi-bin. How big would the C project be before it started to become difficult to work on by virtue of its many lines of code? I'm not saying these new frameworks solve any kind of difficult theoretical problems by the way. And it's still work to make a django or Rails site. But there are many startups that got going in the last decade with just a few people that during the dotcom bubble might have taken 30, 50, even 100 folks to try and turn into reality.
补充以 npm 为例说明复用的利弊
npm 是“买 vs 造”理念的好例子——能调用别人的代码何必自己写？但随之而来的是 left-pad 事件这类问题。
nuc1e0n查看英文原文
npm is a good example of the "buy vs build" idea, although npm modules are mostly free of course. Why write code when you can just call someone else's? But then you get problems like the left-pad fiasco
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2015Hacker News 讨论帖10 分 · 0 评
- 2015Hacker News 讨论帖55 分 · 34 评
- 2019Hacker News 讨论帖110 分 · 85 评
- 2022Hacker News 讨论帖114 分 · 43 评
同领域还值得读
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 分钟编辑精选