编程与软件工程tonsky.me编辑精选
软件幻灭
Software Disenchantment (2018)
2018 — 2022，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 Nikita Prokopov（tonsky）2018 年的长文《软件祛魅》，列举现代软件在体积、启动速度、内存占用和复杂度上的种种退化，质疑为什么硬件越来越快，软件却越来越臃肿、难用。作者认为这不是个别现象，而是行业普遍失去了对效率与质量的追求。
为什么经久不衰：它用大量直观案例戳中每个开发者和用户的日常体验，且文中指出的激励错位与复杂度膨胀在今天依然成立。
HN 评论精选
性能的边际收益递减，易用性和迭代速度常比极致性能更重要。
这个类比反了。真正该问的是：从每百公里 0.5 升降到 0.05 升、再到 0.005 升，人们愿意为这点提升牺牲多少舒适性、性能和价格？当性能已够用，用户因糟糕 UI 和误操作浪费的时间往往比性能更多；因此为快速迭代而承受的复杂度/性能开销是合理的，但要警惕只增加复杂度、没带来敏捷的技术。
rogerdb查看英文原文
> Would you buy a car if it eats 100 liters per 100 kilometers? How about 1000 liters? I think the analogy here is backwards. The better question is "how much would you prioritize a car that used only 0.05 liters per 100km over one that used 0.5? What about one that used only 0.005L?". I'd say that at that point, other factors like comfort, performance, base price, etc. become (relatively) much more important. If basic computer operations like loading a webpage took minutes rather than seconds, I think there would be more general interest in improving performance. For now though, most users are happy-enough with the performance of most software, and other factors like aesthetics, ease-of-use, etc. are the main differentiators (admittedly feature bloat, ads, tracking, etc. are also a problem, but I think they're mostly orthogonal to under-the-hood performance). These days, I think most users will lose more time and be more frustrated by poor UI design, accidental inputs, etc. than any performance characteristics of the software they use. Hence the complexity/performance overhead of using technologies that allow software to be easily iterated and expanded are justified, to my mind (though we should be mindful of technology that claims to improve our agility but really only adds complexity).
软件退化背后是市场速度和晋升激励，而非单纯技术缺陷。
我同意一切更慢更糟，但不只是技术问题。一是上市速度：做没人要的正确东西比做有人很想要的烂东西更糟，所以用 Electron 合理，但用户承担后果。二是软件数量级，在人类尺度上不到 1 倍的改进投资回报不高，300MHz 时值得优化的事在 1GHz 时不成立。三是有前 Google 员工说，维护现有软件或提速没人记功，晋升靠新项目，于是同一项目出现四五个版本，都做得不怎么样。需要解决激励结构，而不只是技术缺陷。
iamwil查看英文原文
I agree it's all slower and sucks. But I don't think it's solely a technical problem. 1/ What didn't seem to get mentioned was the speed to market. It's far worse to build the right thing no one wants, than to build the crappy thing that some people want a lot. As a result, it makes sense for people to leverage electron--but it has consequences for users down the line. 2/ Because we deal with orders of magnitude with software, it's not actually a good ROI to deal with things that are under 1x improvement on a human scale. So what made sense to optimize when computers were 300MHz doesn't make sense at all when computers are 1GHz, given a limited time and budget. 3/ Anecdotally (and others can nix or verify), what I hear from ex-Googlers is that no one gets credit for maintaining the existing software or trying to make it faster. The only way you get promoted is if you created a new project. So that's what people end up doing, and you get 4 or 5 versions of the same project that do the same thing, all not very well. I agree that the suckage is a problem. But I think it's the structure of incentives in the environment that software is written that also needs to be addressed, not just the technical deficiencies of how we practice writing software, like how to maintain state. It's interesting Chris Granger submitted this. I can see that the gears have been turning for him on this topic again.
文章页面本身也臃肿，批评者应先以身作则。
来自 Reddit 评论：我同意总体情绪，但必须指出这个页面本身——一篇基本只有文字的博客——在我电脑上也有 Windows 95 的一半大，含 6MB JavaScript，比 Linux 1.0 的代码还多。Linux 那时已有各种驱动、文件系统、TCP/UDP/IP/ARP/Ethernet/Unix socket、IEEE754、MIDI 等。要指责别人先从自己开始；Web 不必这样，2018 年也能做不含 Google Analytics 的网站。
surround查看英文原文
From a Reddit comment: > While I do share the general sentiment, I do feel the need to point out that this exact page, a blog entry consisting mostly of just text, is also half the size of Windows 95 on my computer and includes 6MB of javascript, which is more code than there was in Linux 1.0. Linux at that point already contained drivers for various network interface controllers, hard drives, tape drives, disk drives, audio devices, user input devices and serial devices, 5 or 6 different filesystems, implementations of TCP, UDP, ICMP, IP, ARP, Ethernet and Unix Domain Sockets, a full software implementation of IEEE754 a MIDI sequencer/synthesizer and lots of other things. >If you want to call people out, start with yourself. The web does not have to be like this, and in fact it is possible in 2018 to even have a website that does not include Google Analytics. https://www.reddit.com/r/programming/comments/9go8ul/comment/e6689uu
应把用户等待时间当作真实生命成本来优化。
很久前看早期 Apple 纪录片，管理层鼓励开发者把启动时间缩短 10 秒，理由是 10 秒乘以启动次数会节省许多人的生命时长。软件界需要更多这种思维，而不是‘程序员时间比 CPU 时间便宜’这类常忽略外部性的论点。
FartyMcFarter查看英文原文
Long ago I watched a documentary about the early Apple days, when management was encouraging their developers to reduce boot times by 10 seconds. The argument was that 10 seconds multiplied by the number of boot sequences would result in saving many human lives worth of time. Edit: found a link with the same story: https://www.folklore.org/StoryView.py?story=Saving_Lives.txt The software world needs more of this kind of thinking. Not more arguments like "programmer's time is worth less than CPU time", which often fail to account for all externalities.
历次讨论
同类还值得读
开源应用架构
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编辑精选