编程与软件工程tinyclouds.org
我讨厌几乎所有软件（Ryan Dahl）
I hate almost all software (2011)
2017 — 2021，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 Ryan Dahl（Node.js 之父）2011 年写的一篇著名吐槽，痛斥几乎所有软件都做得太复杂、太不体贴：安装麻烦、依赖混乱、界面糟糕，连他自己的 Node.js 也不例外。文章短小尖锐，多年来反复引发程序员共鸣。
为什么经久不衰：它道出了软件行业积弊——不必要的复杂性和对用户的不体贴——十多年后这些问题依然存在，每次重读都能引发强烈共鸣。
HN 评论精选
绝大多数开发者有复杂性癖好，真正的天才是不加任何多余东西就解决问题
年纪越大、经验越多，我越发现自己变成了一个极端的复杂性洁癖者。每次看到有人在任何层面引入并非 100% 必要的东西，都会触发一种积累的 PTSD，几乎让我生理性痛苦。我知道人人都说自己喜欢简单，但我的观察是约 95% 的开发者有复杂性癖好——只要有机会，他们就会在必需之外加东西。对很多人来说这几乎是价值观的一部分（如果我只解决基本问题，那我就是个平庸的开发者，对吧？我想当个开发框架、发明新东西让别人用的摇滚明星）。而在我看来，天才的极致是找到不引入任何额外东西就能解决问题的方案。我知道 80% 读到这里的读者会点头认同，然后照样把自己当例外，去创建又一个抽象类、又一个可选配置文件……
zmmmmm查看英文原文
The older and more experience I get the more I find myself turning into a complexity zealot, to a really extremist extent. Every time I see something introduced at any level that isn't 100% strictly necessary to the problem being solved it triggers a kind of accumulated PTSD is almost physically painful. I know everyone thinks they like simplicity but my observation is that about 95% of software developers have a complexity fetish. Literally any opportunity they get to introduce something over and above what is essential to the job they are doing they will do it. For many its almost built in as a part of their value system (if all I do is solve the basic problem then I'm just a mediocre mundane developer right? I want to be a rock star who develops frameworks and invents new things that other people use). And yet the epitome of genius in my mind is finding the solution that solves the problem without introducing anything at all. Again, I know 80% of the people reading my comments right here will nod their heads and identify with it and yet still go away and see themselves as exceptions to the rule and create another abstract class or define an optional configuration file or make their code automatically parse an extra environment variable with a regular expression or .... you get it.... We had to add something to the database the other day. Big argument. Should be one to many? many to many? what if this or that happens? what if requirements change? You know what - for the requirement wa actually had it was solvable with a single integer field on an existing table. But this is a battle that has to be fought ... over and over and over ...
从恨软件转向理解：软件是组织文化的产物，完美可靠在规模化下不可能
还有更高的一层境界：你恨一切东西，但转而热爱那些制造这些烂摊子的人。我买了辆新卡车，开了 100 英里变速箱就出问题，店里查不出原因，下周要整个换掉。我可以说'我干嘛买这牌子'，或者嘲笑他们是菜鸟，但我意识到他们是在大规模制造东西，坏事总会发生，所以我接受这个不便，继续生活。我恨软件很久了，因为我看重精确和可靠，但这在组织层面极难规模化——今天修好了可靠性，明天的功能又可能把它搞砸。现在我仍然恨软件，但换了一种心态：软件是一种需要呵护和关爱的文化的产物。
mathgladiator查看英文原文
There is one more level where you hate everything, but then embrace loving the people that make shit. I bought a new truck, and after putting 100 miles on it the transmission started acting strange. I take it in, and they don't know what is wrong with it. So, they are going to replace the entire transmission next week. Now, I could say "oh, why did I buy that brand" or be like "lolz, these people are n00bs". Instead, I realize that they are making something at a massive scale and bad things will happen, so I'll accept the inconvenience and move on with my life. Shit happens, and that's life. I've hated software for a long time because I value precision and reliability, but these are exceptionally hard to scale organizationally. Suppose you fix reliability today, well tomorrow's feature could just fuck it up. Now, I still hate software, but I come at with a mindset that software is an artifact of a culture which requires nurturing and love.
有些复杂性是问题本身固有的，过度简化反而制造新问题
这话得两面看。我当然恨不必要的复杂性，但有些东西就是复杂的。好例子是字体渲染和文本输入——你以为会很简单，其实不是，真的不是。而且软件也常常过于简单。我刚买了'智能灯泡'（我的错误），用 Apple Home 控制，3 个灯泡装在一个落地灯里，Home 没法把它们标记为一盏灯，只能当成 3 盏。 supposed 的解法是用普通灯泡加智能开关，但那样就不能调色了。更糟的是，如果家里来客人，我出门时把灯关了，他们就没法开灯。也许断电恢复后灯应该默认全亮白光？但设计成那样反而又是更多复杂性。我的 Siri 还设成了日语，英语客人连语音都问不了。复杂性，因为世界本身是复杂的。
greggman3查看英文原文
It goes both ways. I certainly hate un-needed complexity but somethings are just complex. Good examples are font rendering https://gankra.github.io/blah/text-hates-you/ and text input https://lord.io/text-editing-hates-you-too/ You think it's going to be easy. It's not. It just isn't. Often software is too simple. I just recently got my first "Smart Lights" (my mistake). I'm using Apple Home to control them. I put 3 bulbs in a 3 bulb standing lamp. Home has no way to for me to designate those as a single lamp. To Home they are 3 lamps. The solution is supposed to be use normal bulbs and a smart switch. But that precludes being able to set the colors of the bulbs. In other words, they thought it was simple but it's not. It gets worse. At first I thought this would be cool, but now I realize if I have a house guest, they won't be able to turn on the lights if I left them off. Arguably, if the power is cut and comes back on, maybe the lights should default to full white? At least then, in an emergency they just work. But again, designing lights that do that would be more complexity, not less. I can even add another wrinkle. My Siri is set to Japanese. So, my English speaking house guests will not be able to ask for the lights to be turned on if I had a HomePod, which I don't. More complexity because the world is complex
从炫技者转变为实用主义者：花哨是代码坏味道，解决方案应尽量自包含
年纪越大，我越认同这篇吐槽。我曾是那个在测试运行器里放可爱 unicode 勾选框的人，自以为在让世界更美好。现在我明白，我的时间本该用来解决问题然后去做下一个问题。没人在渴望动画对勾，而我可能因为别人的终端模拟器 unicode 支持太差而毁了他们的体验。当然这是一种微妙的平衡——爱折腾的人往往在推动技术前进，但代价高得惊人：光动态链接这些烂摊子就消耗了多少人的一生？为了解决一个我们 1992 年后就不该再有的一类问题。真是浪费。我越来越疲惫的自己只想让东西能用，好合上电脑出门陪孩子。
monodeldiablo查看英文原文
The older I get, the more I agree with this rant. I used to be that guy putting cute unicode checkboxes in his test runner, telling myself I was making the world a better place because my software was nifty and clever. Now, I realize that, while that's nice to see, my time was better spent just solving the problem and then moving on to the next problem. Nobody was dying for animated tick marks and I probably ruined someone's experience because their terminal emulator or multiplexer had shitty unicode and escape code support. It's a delicate balancing act, of course. The tinkerers are often the ones pushing tech forward with their incessant fiddling. But it comes at such an incredibly high cost. I mean, how many human lifetimes have been consumed by the shitty intricacies of dynamic linking alone. And for what? To solve a class of problems we haven't really had since 1992? What a waste. There's ample space in the software world for all kinds -- and arguably the industry is fueled by the blood of well-intentioned innocents -- but my increasingly jaded self just wants the shit to work so that I can close my laptop and get outside with my kids. The guy who spent 15 hours a day obsessing over The Right Way and code purity and ecosystems has aged into a man who firmly believes that less is much more, cuteness is a code smell, and solutions should be as self-contained as humanly possible.
历次讨论
同类还值得读
开源应用架构
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编辑精选