编程与软件工程paulgraham.com编辑精选
在头脑中把握一个程序
Holding a Program in One's Head (2007)
2007 — 2024，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
Paul Graham 2007 年的经典文章《把程序装在脑子里》：论述程序员为何需要将整个程序完整地保存在头脑中才能高效工作，并给出实现这一状态的条件——避免干扰、使用简洁的语言、亲自重写代码、减少分心等。文章还讨论了打断对思维的破坏性，以及大公司协作环境与这种工作方式的冲突。
为什么经久不衰：它精准道出了深度专注与打断成本这一编程核心矛盾，十几年后依然是关于程序员生产力的必读之作。
HN 评论精选
用牛顿的例子佐证：把问题长驻脑中正是伟大思考者的核心能力
引用凯恩斯对牛顿的描述：牛顿的天赋在于能将一个纯思维问题持续保持在头脑中数小时、数天甚至数周，直到它向他交出秘密。这种持续专注的内省能力才是他超凡直觉的来源。
segmondy查看英文原文
I'll leave this here “I believe that the clue to his mind is to be found in his unusual powers of continuous concentrated introspection. A case can be made out, as it also can with Descartes, for regarding him as an accomplished experimentalist. Nothing can be more charming than the tales of his mechanical contrivances when he was a boy. There are his telescopes and his optical experiments, These were essential accomplishments, part of his unequalled all-round technique, but not, I am sure, his peculiar gift, especially amongst his contemporaries. His peculiar gift was the power of holding continuously in his mind a purely mental problem until he had seen straight through it. I fancy his pre-eminence is due to his muscles of intuition being the strongest and most enduring with which a man has ever been gifted. Anyone who has ever attempted pure scientific or philosophical thought knows how one can hold a problem momentarily in one's mind and apply all one's powers of concentration to piercing through it, and how it will dissolve and escape and you find that what you are surveying is a blank. I believe that Newton could hold a problem in his mind for hours and days and weeks until it surrendered to him its secret. Then being a supreme mathematical technician he could dress it up, how you will, for purposes of exposition, but it was his intuition which was pre-eminently extraordinary - 'so happy in his conjectures', said De Morgan, 'as to seem to know more than he could possibly have any means of proving'. The proofs, for what they are worth, were, as I have said, dressed up afterwards - they were not the instrument of discovery.” ― John Maynard Keynes
逐条商榷 PG 的论点：语言规则性、限制性和简洁性在不同场景下的权衡
PG 的观点接近但未完全到位。关于规则性：Ruby 只有 nil 和 false 为假值，而 Python 把空值也当假值，导致假设被打破（如午夜整点被判定为假，3.5 才修复）。关于限制性：小团队的专业人士喜欢不受限的语言，大项目则相反——所以 Go 适合 Google，Ruby 适合初创公司。关于简洁与可读性：正则很简洁但可读性差，简洁性关乎字符数，可读性关乎理解时间，二者相关但简洁的进一步收益并不提升理解速度。
3pt14159查看英文原文
He's close to how I think about it, but not quite there. On regularity: Take the handling of what is false-y. In Ruby only nil and false are false-y. If you use an && the only way it can come out false is if one of the two sides is nil or false. Python, on the other hand, tries to treat emptiness as false-y. It leads to irregularities because assumptions are broken. The clearest example was that the exact second of midnight was considered false-y. Fixed in 3.5 if memory serves. On restrictiveness: I agree with PG that a pro working on a project with a small set of other pros prizes unrestrictive languages. On large projects it is usually the opposite. This is why Go is great for Google, but Ruby is great for startups. On conciseness vs readability: Regex is concise, but it is shit at readability. The reason conciseness is less important than readability is that conciseness is about the character count while readability is about the time it takes to understand. They're related, but only to a point. Ruby is much more concise than assembly, and that helps its readability, but further gains in conciseness don't really impact speed to understanding. Regex is fine for a grep of your own filesystem because you're the one writing it so you know you understand it. But for complex form validation it's usually not the first tool I reach for because I tend to assume that the person that comes in behind me might not know more than the basics. Even when I do use them, I break them up as strings into variables that name what they do before concatenating them.
真实职场中被打断的痛苦，印证了文章对干扰成本的论述
真希望能把这篇文章发给同事而不显得刻薄。他坚持要'一起工作'——在同一空间做不同项目，每两分钟就用无关问题打断我的思路。我快到崩溃边缘了，想说：'这样协作可能提升你 50% 的效率，却让我的效率降低 80%。'
daenz查看英文原文
I wish there was a way to send this to my programmer coworker without seeming like a jerk. He insists we "work" together, meaning, we're in the same physical space, working on two different projects, and he interrupts my train of thought every 2 minutes with an arbitrary question about the thing he's working on. I'm close to a snapping point and don't know how to address it tactfully. What I want to say: "us working together may enhance your productivity by 50% but slows mine down by 80%."
反驳：靠抽象和关注点分离降低脑内负担，比硬记整个程序更根本
警告：争议观点。文章搞错了重点——把程序装在脑子里本来就不应该是必需的。真正的问题是复杂性，而复杂性要靠抽象来解决：把问题拆成可管理的组件，程序员在系统层或组件层工作，从而最小化需要记住的内容。如果你在高低抽象层之间来回切换，说明该重新审视架构了。这叫关注点分离，任何工具改进都解决不了这个问题。
Spearchucker查看英文原文
Warning: controversy. The text misses the point in that having to hold a program in one's mind is not required to begin with. The real problem is complexity. There's just so much going on that it's difficult to remember. And complexity is solved through abstraction - separating the problem out into manageable components. That way the programmer works at a system level, at which components are composed into a solution, or at the component level, where one specific aspect is dealt with. That minimizes the amount of stuff the programmer needs to hold in his head. If you find yourself oscillating between higher and lower levels of abstraction you should probably be revisiting your architecture. It's called separation of concerns. No tool improvement is going to solve that. Neither will a rethink of ways of working.
修正理解：'装在脑子里'实为掌握全局结构以便按需定位细节
把大程序装进脑子就像把一座城市装进脑子——你不可能完全做到。你能做的是掌握大致轮廓和原则，从而能导航到相关位置并处理难点，就像出租车司机不必记住每块鹅卵石和坑洼，但知道怎么到达目的地。
stcredzero查看英文原文
Holding a large program in your head is like holding a city in your head. You can't entirely do it. What you can do is to know broad outlines and principles, so you can navigate to the relevant points and negotiate difficult parts. When you see the details at the relevant places, then you can deal with them. It's like being a cab driver. You don't memorize every cobblestone and pothole, but you know how to get where you need to go you can deal with them as you're driving.
读者现身说法：这篇文章支撑了他完成高强度复杂开发
这是 PG 最有帮助、最令人安心的一篇技术文章。最近我在开发复杂算法、面对海量边界情况时，连续工作 15 小时以上，还每隔一天禁食（只喝咖啡、吃少量坚果和水）来保持状态。若不是读过并内化了这篇文章，我可能撑不到今天。
mtraven查看英文原文
It's actually an indictment of our programming tools that they require one to hold so much of the design context in one's head. If they were better (more expressive, easier to interact with) they would help to solve the problems rather than require superhuman feats of endurance. pg does mention that succinct programming languages help, which is true, but they don't go nearly as far as they could. Like him, I use Lisp for that very reason, but Common Lisp is 30 years old -- why hasn't the state of the art advanced since then? It's really quite shameful.
历次讨论
同类还值得读
开源应用架构
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编辑精选