编程与软件工程yosefk.com
底层很简单
Low-level is easy
2014 — 2021，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 Yossi Kreinin（yosefk）的一篇经典博文，核心论点是：越往底层写，反而越"容易"。高层开发要面对成千上万个你无法控制、也不完全理解的框架、约定和脆弱的依赖，出了问题只能绕过去；而底层的行为由机器决定，规则有限，可以彻底搞明白，也能自己修。
为什么经久不衰：它把"抽象泄漏"带来的日常挫败感讲得极其清楚，每当高层生态再膨胀一轮（前端框架、游戏引擎、依赖地狱），这个反直觉的论点就会被重新翻出来讨论。
HN 评论精选
亲身经历印证：为了摆脱脆弱依赖不断下沉，且能自举/能改下层是巨大优势。
我这几年从很"高层"的编程（客户端/服务器应用、数据库驱动的网站）转到"中层"（Firefox 浏览器），再往系统编程走（Rust 和 Servo），发现这话非常对。想摆脱大量脆弱依赖的愿望一直把我往栈的更深处推。如果项目能自举、或者你能控制上下一层的代码，也能得到类似的好处：网页开发者碰到渲染引擎的 bug 只能报上去、然后打三年 workaround；而 Firefox 前端开发者可以直接修 Gecko 的 bug 并随功能一起发布。
mbrubeck查看英文原文
I've found this very true, as I've moved over the years from very "high-level" programming (client/server apps, database-driven web sites) to "mid-level" programming (working on the Firefox browser) and then toward systems programming (working on Rust and Servo). The desire to stop dealing with masses of fragile dependencies keeps driving me lower in the stack. I really need to practice more assembly coding so I can continue in this direction... You get some similar benefits if you are working on code where you have some control over the levels above or below, or if your project has any form of self-hosting. For example, Firefox, where most of the UI is rendered by Gecko and some of it even runs within a browser tab. If you're a web developer and you run into a rendering engine bug, you report it and then ship a workaround for three years as you wait for enough people to update. If you're a Firefox front-end developer, you can just fix the Gecko bug and ship the fix along with your feature.
反驳"容易"：底层调试痛苦、没有保护，只是更好玩。
至少底层好玩得多。但我不觉得它"更容易"。第一次打开调试器发现虚表指针是空的时候（前提是你知道什么是虚表指针），事情就变得有意思了。还有那次 printf 一个 64 位数时某个栈变量被莫名破坏。内存保护？哈哈，没有。几周前我团队还遇到一个 bug：一次 DMA 内存拷贝的同时向同一个外设发命令包——oops。指望系统帮你排序？不会的，除非你自己实现排队机制。总之非常有意思，我很享受。
com2kid查看英文原文
Low level is a lot more fun in the very least. I wouldn't say it is easier by any means. The first time you open up the debugger and your v-table pointer is null (presuming you know what a v-table pointer is!) things start to be interesting. Or there was that time I printf'd a 64bit number and a random stack variable was corrupted. That was a lot of fun. Memory protection? Haha. No. For that matter, my team just came across a bug in our own code a couple weeks ago, we were performing a DMA memcopy operation (for which you get to setup your own DMA descriptors yourself of course) over a bus and at the same time sending a command packet to the same peripheral that was being DMA'd to. oops. Expected things to be put into order for you? Nope. Not unless you implement your own queuing system. (Which we are doing for that particular component now.) All in all it is a ton of fun though. I'm loving it. Having seen an entire system be built up from setting up a clock tree to init'ing peripherals to our very own dear while(1). (We actually moved away from while 1, async is where it is at baby! Callback hell in kilobytes of RAM! oooh yaaaah)
区分不同意义的"难"：底层的门槛在前期学习成本，不能因此说它容易。
我明白作者的意思，也部分同意；但"难"和"易"有不同种类。要在底层做出有价值的东西，你必须对那一层有非常全面的理解，前期学习成本（以及天赋门槛）很高，而文章基本没提这一点。掌握之后确实惊喜很少，但获得它本身一点都不"容易"——只是老手忘了当年花了多少力气，因为学的时候很快乐。在高层，你可以把 Stack Overflow 上粘来的框架和胶水拼起来，大多数时候勉强能用。哪个更"容易"取决于你怎么定义。
georgemcbay查看英文原文
I get the point of the blog author and I partly agree with it; but there are different types of "hard" and "easy". To produce much of value at the low-end you need a really comprehensive understanding of the technology at the level you are working at which has significant upfront learning (and likely just plain aptitude) costs that aren't really addressed too much here. Once you have that knowledge, then yes, you get far less surprises, but acquiring it in the first place is not at all trivial or "easy" (though it may seem like it if you're a geek that's been banging away with assembler for years... you've just forgotten how much effort you expended at that stage, probably because it felt fun to learn). At the higher-end you can string together a bunch of frameworks and glue code you cut and pasted off Stack Overflow and get something that pretty much does what you want, most of the time, maybe, while barely understanding the underlying technology. Which is "easier" or "harder" depends a lot on what you mean by those terms. Also the assumption that "high-level" means HTML/CSS/JavaScript is not that useful for the overall debate since not all high-level development is as annoyingly unpredictable as HTML/CSS/JavaScript.
自研引擎比学大型游戏引擎更容易出成果，因为能掌控整个栈、从源头修 bug。
这在游戏开发里体现得淋漓尽致。我试过 Unity、Unreal 和 Godot，但什么都做不出来，要学的东西太多——绑定、粒子系统、AI 寻路，还有各种奇怪的 bug 和绕行方案。Unity 尤其像是拼凑出来的，每件事都有多种做法（DOTS、UI、动画），有能用的"legacy"方式和坏掉的"beta"方式。相反，我自己写引擎，虽然什么都要自己做，却容易得多：我只需要懂图形和代码。引擎有 bug 我可以直接从源头修。当然这让我只能做小游戏、也更难协作，但总比一个游戏都做不出来好。
armchairhacker查看英文原文
This applies so much do gamedev. I’ve tried Unity, Unreal, and Godot. But I’ve never been able to produce anything, because there’s just so much to learn. Rigging, particle systems, AI pathing, etc. And so much weird bugs and workarounds. Unity in particular sometimes seems like it was hacked together, and there’s always multiple ways to do everything (DOTS, UI, animation), the broken “beta” way and the “legacy” way. In contrast, I write my own engine, and even though I have to make everything it’s so much easier. All I need to know is graphics and code. My game engines are much more intuitive to me because I wrote them. And no workarounds, because if the engine has a bug, I can fix it at the source. Of course, this means I end up making smaller games and it’s harder to collaborate with others. But it’s better than no games at all. With the like 20+ different game engines out there I know I’m not alone.
历次讨论
同类还值得读
开源应用架构
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编辑精选