编程与软件工程spectrum.ieee.org
2024 年对精简软件的呼吁
A 2024 plea for lean software
2024 — 2025，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇 IEEE Spectrum 文章是一份“精简软件”的呼吁：作者认为当代应用动辄基于 Electron、层层依赖和云服务，变得臃肿、脆弱且难以理解，主张回归更小、更简单、更可控的软件。文章批评“把一切交给平台或云”的心态，并讨论团队为何不断堆叠复杂度。
为什么经久不衰：它点中了跨越语言和年代的普遍痛点——依赖膨胀与交付压力下的代码腐化，今天读来仍能解释我们日常遇到的软件臃肿。
HN 评论精选
npm/Rust 生态中库功能过度膨胀、用户追求“全能库”，导致依赖失控；他提议用“低依赖”徽章引导选择。
臃肿主要体现在 npm 上的大多数库。作者不懂好的设计，反而想让每个库什么都做。哦，我的库做字符串编码转换，那我就让它顺便帮你加载文件、保存文件、从网上下载，再提供一个命令行工具，全塞在同一个仓库里。库应该只做一件事，其余交给用户。我觉得 Rust 那边也好不到哪去。去试着编辑一下 Rust 文档，看它装大约 1000 个 crate。问题不在语言，而在于任何人都能发布库（我不是抱怨这一点），而且大家也确实这么干。“只想把事做完”的人会选功能最多的库，然后还求着加更多功能，因为他们懒得写那三行本可在库外解决的代码。“你能加个渲染 PDF 吗？”我不知道怎么解决。我的一个想法是发起一个“低依赖”倡导组织，弄个徽章之类，推动人们希望自己的库挂上这个徽章，也让用户在选择库时寻找这个徽章。
nox101查看英文原文
Bloat is most libraries on npm. The authors don't know good design and instead try to make every library do everything. Oh, my library converts strings from one encoding to another, I'll make it load files for you, save files for you, download them over the internet, and give you a command line tool, all in the same repo. The library should just do its one thing. The rest should be left to the user. I get the impression it's no better in rust land. Go try to edit the rust docs. Watch it install ~1000 crates. The issue is not the language, it's that anyone can post a library (not complaining) and anyone does. People who "just want to get stuff done" choose the library with the most features and then beg for even more since they can't be bothered to write the 3 lines of code it would have been to solve it outside the library. "Can you add render to pdf?" I don't know how to solve it. My one idea is to start an "Low Dependency" advocacy group with a badge or something and push to get people to want that badge on their libraries and for people to look for that badge on libraries they choose.
用系统原生 WebView 替代 Electron 可大幅减小体积，并保留后端技术选型自由。
没多少人意识到，你可以使用各平台原生的 Web 控件，而不是打包 Electron。这样做的话，分发出去的应用可以只有几 KB。这种方法还让你能自由选择任何后端编程语言/技术栈，只要它能和 WebView 通信。
hgs3查看英文原文
> A typical app today is built on Electron JS Not enough folks seem to realize but you can use each platforms native web control rather than bundling electron. If you do that your distributed app can be in the kilobytes. This approach also gives you the freedom to use whatever backend programming language / tech stack you want so long as it can communicate with the web view.
现代包管理的便利会纵容依赖膨胀；C/C++ 的摩擦反而迫使人们谨慎引入库、控制代码规模。
我开始觉得 C 和 C++ 传统依赖管理的糟糕状况其实是件好事。现在用 npm、maven、cargo 这类系统，要获取一个包只需在配置文件里加一行，它就会自动从中央仓库拉取所有依赖。非常方便，但你会很快发现自己有 100 多个来路不明的包和数百 MB 代码。在 C 里，传统上每引入一个库都需要斟酌：没有自动下载，用户手上的库可能和你开发时用的版本不同，你得兼容，库发布者也得兼容；或者你得把库随代码一起发布。总之很麻烦，所以最简单的办法往往是不用库、自己写，甚至更好——意识到你根本不需要那个功能。理由不好，重复造轮子也有自己的问题，但至少最终代码规模可控。
GuB-42查看英文原文
I am beginning to think that the terrible situation with dependency management in traditional C and C++ is a good thing. Now, with systems like npm, maven or cargo, all you need to do to get a package is to add a line in a configuration file, and it fetches all the dependencies you need automatically from a central repository. Very convenient, however, you can quickly find yourself with 100+ packages from who knows where and 100s of MB of code. In C, traditionally, every library you include requires some consideration. There is no auto-download, and the library the user has may be a different version from the one you worked with, and you have to accommodate it, and so does the library publisher. Or you may have to ship is with your own code. Anyways, it is so messy that the simplest solution is often not to use a library at all and write the thing yourself, or even better, realize that you don't need the feature you would have used that library for. Bad reason, and reinventing the wheel comes with its own set of problems, but at least, the resulting code is of a manageable size.
冲刺交付压力挤掉了清理和精简代码的时间，导致安全和文档等隐性质量被牺牲。
一个大问题是团队被期望的交付速度。如果每个 sprint 都要给用户交付价值，系统里就没有足够余量回头修剪代码、清除腐化。人们为了赶上管理层定的截止日期而偷工减料。被砍掉的角落是演示里看不见的东西：安全、文档，以及把所有东西粘在一起的口香糖。
al_borland查看英文原文
A big issue is the speed at which teams are expected to deliver. If every sprint is expected to deliver value to the user, there is isn’t enough slack in the system to go back and prune the code to remove cruft. People end up cutting corners to meet deadlines set by management. The corners that get cut are the things that are invisible in the demo. Security, documentation, and all the chewing gum holding it all together.
历次讨论
同类还值得读
开源应用架构
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编辑精选