编程与软件工程charlespetzold.com
Visual Studio 会让大脑生锈吗？（2005）
Does Visual Studio Rot the Mind? (2005)
2020 — 2025，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 Charles Petzold 2005 年在纽约微软 WPF 发布会上的演讲稿，探讨 Visual Studio、IntelliSense 和可视化设计器等工具是否在削弱程序员的思考与记忆能力。文章批评了“先写代码再让工具补全”的编程方式，以及 XAML 等声明式 UI 技术带来的复杂性。
为什么经久不衰：它提出的问题——智能工具是放大还是侵蚀了程序员的能力——在 AI 辅助编程时代反而更加切中要害，因此二十年来反复被重新发现和讨论。
HN 评论精选
现代工具已能“先使用后生成”，Petzold 对 IntelliSense 限制编程顺序的批评已过时
> 为了让 IntelliSense 正确工作，最好采用自底向上的编程方式。IntelliSense 要求每个类、方法、属性、字段、方法参数、局部变量在你引用之前都已定义好。否则它会试图用已定义的东西来纠正你的输入，而那很可能是完全错误的。也许是我被 Resharper 之类的工具惯坏了，但我觉得这个说法现在不成立了——有了“生成属性”“生成类”“生成方法”这些按钮，我常常直接先用一个变量，再点一下生成让它存在。尤其在 C++ 世界里，这意味着要改头文件、重写类型、复制函数原型等等，这些功能是巨大的时间节省。
arsome查看英文原文
> In order to get IntelliSense to work correctly, bottom-up programming is best. IntelliSense wants every class, every method, every property, every field, every method parameter, every local variable properly defined before you refer to it. If that’s not the case, then IntelliSense will try to correct what you’re typing by using something that has been defined, and which is probably just plain wrong. Maybe I'm spoiled by Resharper and similar, but I feel like this statement is wrong now, given the buttons for "generate property", "generate class", "generate method", etc. I often just start using a variable and then click generate to make it exist. Especially in the C++ world where it means editing a header file, rewriting the type, duplicating the function prototype, etc this is a big time saver.
亲身经历证明：大项目里 IDE 的导航和重构能力远胜文本编辑器，“脑腐化”担忧可以放一边
本周的亲身经历：我在做一个 Python 项目，类和子类很多，代码路径在类层次间来回跳转。我想加一个功能，却一直被“确保所有子类实现同一接口”这件事拖住，当时用的是 Atom 编辑器。后来我装了 PyCharm，靠“查找引用”和跳转到定义，几个小时就完成了任务，还顺手重构了一些糟糕的变量名。我一直出于“避免脑腐化”的理由在个人项目里讨厌 IDE，但现在开始觉得，项目足够大时你就是需要 IDE。唯一的缺点是所有操作都有几毫秒延迟——每次滚动或点击，后台都在做大量工作，而 Atom 几乎是即时的。
ivan_ah查看英文原文
Anecdote from this week: I've been working on a Python project that uses several classes and subclasses, with code paths that move around a lot through the class hierarchy. I was trying to add some functionality but kept getting bogged down trying to make sure all the subclasses implement the same interface, using Atom as the text editor. Then I installed PyCharm and completed the task in just a few hours thanks to the "find uses" and jump to definition functionality. I was also able to refactor some less-than-good variables names. I've always hated IDEs for personal projects (to avoid mind-rot), but now I'm starting to think for large enough projects you just need an IDE. The only drawback I see is a few millisecond lag on all actions. Every time you scroll, or clock on something there is a lot of things going on in the background, vs. Atom which feels near-instant.
对比 WPF 与 WinForms：XAML 更可评审，但 WPF 的自由和复杂性常被滥用
虽然他的一些抱怨如今已有解决方案，但如果谨慎使用，WPF（旧称 Avalon）生成的 XAML 比 CodeDOM 序列化方式更易于 diff 和代码评审——后者非常紧凑，小小的改动会造成巨大的代码差异。另一方面，WPF 比 WinForms 复杂得多，用法繁多，很多涉及运行时才求值的数据绑定。WinForms 的数据绑定很有限，所以通常更容易追查是哪段代码让某个东西显示在屏幕上。WinForms（以及更早的 Win32 资源脚本）能表达的东西有限，因此产出的 UI 在视觉和行为上往往比较相似——这对开发者是好事，因为设计已经替你铺好了；对用户也是好事，因为应用更一致、更可预测。WPF 给你一张大画布，很难把东西做得体面，却能让你的应用看起来和任何东西都完全不同。总之，我同意 WPF 能让用心的人写出更易懂的代码，可惜它常被用来堆砌不必要的复杂性。
MarkSweep查看英文原文
While some of his complaints now have solutions[1], when WPF (previously known as Avalon) is used with care, the resulting XAML is much more diff-able and code-review-able. The CodeDOM serialization method is dense and small changes can cause huge code diffs. On the other hand, WPF is a lot more complex than WinForms. There are a lot of different ways to use, many of which involve data binding that is not evaluated till runtime. There are ways to make some databinding type-checked at compile time, but it is not built in. WinForms data binding is pretty limited, so generally it is easier to track down what piece of code is causing something to display on the screen. WinForms (and the Win32 resource scripts that can before it) are more limited in what they can easily express. So the resulting UIs tend to be a bit visually and behaviorly similar. This is nice for devs because you have a design already laid out for you. It's also nice for users since the apps are more consistent and predictable. WPF gives you a big blank canvas where it is hard to make something look decent. And enables making your app look completely different than anything else. So in conclusion, I agree that WPF enables more understandable code to be created by people who care. Unfortunately it is often to used to add a bunch of needless complexity. [1]: For example, the GenerateMember option in the WinForms design can be used to suppress generating fields for controls.
引用原文数据指出：知识复杂性指数增长正在超出人脑容量，这是各领域的共同困境
“二十年前，1985 年 11 月，Windows 1.0 发布时约有 400 个文档化的函数调用。十年后，Windows 95 已超过一千个。今天我们即将正式发布 .NET Framework 2.0，仅统计 MSCORLIB.DLL 和以 System 开头的程序集，就有超过 5000 个公共类，包含 45000 多个公共方法和 15000 个公共属性……”这是现代世界我们永恒的挣扎：复杂性正在超出人脑的容量。物理学、生物学、遗传学都在发生同样的事。我逐渐形成的看法是：复杂性其实是必要的，我们尽力将其最小化，但超过某个程度后就无法摆脱了，而且还在加速。经典物理容易理解，但所有进展已让物理学（及其他领域）对越来越多的人变得难以企及，除非经历多年高度狭窄的附加学习。似乎要理解量子力学最新成果，你在读完 16 年高中加大学之后还得再学 16 年。换句话说，攀爬知识金字塔所需的时间大约每 100 年翻一倍。照此推测，到 2100 年，要登顶可能需要 48 年！
sytelus查看英文原文
"Twenty years ago, in November 1985, Windows 1.0 debuted with approximately 400 documented function calls.5 Ten years later, Windows 95 had well over a thousand.6 Today we are ready for the official release of the .NET Framework 2.0. Tabulating only MSCORLIB.DLL and those assemblies that begin with word System, we have over 5,000 public classes that include over 45,000 public methods and 15,000 public properties..." This is our constant struggle in the modern world where the complexity is simply outstripping the capacity of the human brain. It's happening in physics, biology, genetics... Some authors question why we need all this complexity? Isn't complexity bad? I'm forming a view that the complexity is in fact necessary and we try out best to minimize it but beyond a certain level, it's simply isn't possible to get rid of it. This is only accelerating. Classic physics was easy to understand but all the advances have made physics (and other fields) slowly inaccessible to a larger and larger population without going through intense add-on multi-year narrowly scoped learning. It seems we are at the point that to comprehend the latest in quantum mechanics you need yet another 16 years of learning after you already had 16 years of high school+college. In other words, time to climb the knowledge pyramid doubles approximately every 100 years. By that speculation, in year 2100 the knowledge pyramid might have grown so big that to reach top might need 48 years! At this juncture, it might become apparent that the human life span is simply not enough to climb the knowledge pyramid starting from the basic arithmetic to the latest and greatest in physics anymore. We reach tipping point where biological limitation of life spans, memory capacity, recalls and search become truly limiting. I think this is where AI would be super important. From that point onward, we will need to rely on machines to tell us the simplified, intuitive but inaccurate version of the truth that we can sort of comprehend with our limited hardware, like automated machine-generated 1000+ steps proofs. That would be an interesting world.
历次讨论
同类还值得读
开源应用架构
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编辑精选