编程与软件工程cs.utexas.edu编辑精选
论“自然语言编程”的愚蠢（1979）
On the foolishness of “natural language programming” (1979)
2010 — 2020，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 Dijkstra 1979 年的一篇短文，论证所谓“自然语言编程”是一种愚蠢的想法：自然语言适合交流，却不适合精确描述计算过程，其模糊、冗余和依赖语境会掩盖错误。文章强调编程语言的价值在于形式化与可验证性，而不是模仿日常语言。
为什么经久不衰：它用极简而尖锐的论证点破自然语言编程的核心误区：模糊性不是便利，而是隐藏错误的温床；在自然语言接口和 AI 编程助手流行的今天尤其值得重读。
HN 评论精选
编程语言的“易用”应体现为更容易确信程序正确，而非更容易掩盖错误；命名与语言歧义本身会诱发 bug。
我很喜欢这句引文：“有些人似乎仍把‘编程之易’等同于‘制造未被发现错误之易’。”反过来说，编程之易也可以说等同于（或至少相关于）让人对程序正确性建立信心之易。就文章更广的主题而言，我注意到像 APL 这样真正拥抱符号表达的语言似乎没获得多少地盘；另一方面，语法轻、更多用词语表达的语言（如 Python）却大受欢迎。总体上，这篇文章也关乎“命名很难”这个常见观点：我们给代码元素的名字会带入“用母语时几乎无法避免的各种胡话”。而多少 bug 源于人们根据名字对事物做出假设，因为 Dijkstra 在此谈论的正是这种语言歧义？
zokier查看英文原文
I really like this quote: > some still seem to equate "the ease of programming" with the ease of making undetected mistakes Conversely you could say that ease of programming is equal (or at least correlated) with ease of getting confidence of your programs correctness. On the wider subject of the essay, I do note that languages like APL that really embraced symbolics for expression do not seem to have gained much ground, and on the other hand languages that are light on syntax and use more verbiage like for example Python have been massively popular. Overall I think the essay also relates to the common idea that naming things is difficult. The names we give our elements of code imbue the "all sorts of nonsense that, when we use our native tongues, are almost impossible to avoid". And how many bugs stem from people making assumptions about things based on their names because the sort of linguistic ambiguity etc that Dijkstra is talking about here?
编程语言本质是便于人类推理的抽象机器码，不是简化英语；去掉形式性并不能让计算机理解自然语言。
计算机不“说”任何语言，只执行机器码/指令。从汇编到 C 到 Python，我们从没让计算机理解某种语言；只是用更便于人类推理机器码、类似自然语言的文本来帮助我们。关键点是：编程语言不是把自然语言削减后改作计算机解释用，而是像自然语言的抽象机器码。这意味着所有编程语言本质上都有机器码特征（即便被隐藏），否则就不完整、无法完成我们期望计算机做的事。人们看到代码像英语却有些非技术者不懂的语法垃圾，便想：去掉这些让计算机理解纯英语，那人人都能编程。这一刻他忘了自己看到的是抽象机器码，而非残缺英语。有趣的是，那些声称面向非技术人员的语言，目标只在极有限应用中实现；一旦需要变量和函数……
gtsop查看英文原文
Computers don't speak any language, they exexute machine code - instructions. From assembly, to C, to python, we never made computers understand any sort of language. We managed to help humans reason about machine code in a manner that is more convinient to us, that is some text that resembles our natural languages. But this is the important part, let me repeat this in a different way: Programming languages aren't stripped down natural languages repurposed for computer interpretation. Programming languages are abstract machine code resembling our natural languages. The meaning of this is that all programming languages will inherently have features of machine code (even if they are hidden away), else they would be incomplete, unable to perform all the functions we expect a computer to do. People now look at code as is today, seeing some english-speak that is not completely english and think: hmmm well this looks like english but has some extra syntactic garbage that non-technical people don't understand. What if we removed all these and made the computer understand pure english? Then everyone would be able to program. And this is the moment that the man forgot he is actually looking at abstract machine code rather than handicapped english. I find it very interesting that all languages (the ones I've seen at least) that claim to be for non-technical people achive their goal in a veeery limited set of applications. As soon as one needs variables and functions (and that is usually very soon) things get technical fast.
自然语言依赖即时反馈、指认和澄清对话，直接用作无反馈的编程指令会缺失或冗余；语音编程需要对话式设计。
自然语言经过数万年演化，是供狩猎采集者群体协作完成共同任务用的——也包括争论假设和优先级。在那样的情境中，用手指或展示东西很重要（“放那儿”），来自表情和目光的非语言反馈也重要；群体成员可以问澄清问题，比如“你说的 X 是什么意思？”或“能更具体吗？”，说话者也可以问“你听懂了吗？”。当人们解释任务却得不到接收方理解情况的即时反馈时，自然语言指令很可能漏掉关键信息，或加入不必要的信息。自 2000 年前后在 IBM 语音研究组工作以来，我一直觉得自然语音对编程可能有用，但需要换一种视角，把自然语言当作对话和相关创造性实验，提供与传统编程语言不同的体验；这可能更像结对编程的某些方面。不过 HyperTalk（HyperCard 用的语言）的一大特点就是比多数编程语言更接近自然语言；它支持多种替代表述……
pdfernhout查看英文原文
Natural language is adapted for many tens of thousands of years to be used by groups of hunter/gatherers working together on a common task -- which also includes arguing about related things like assumptions and priorities. In that context, physically pointing or showing things is important ("put it there"). As is also non-verbal feedback from expressions on people's faces or by where their eyes are looking. Also, people in the group can ask clarifying questions, like "What did you mean by X?" or "Can you be more specific?". Or the speaker can ask, "Did you understand what I said?" When people try to explain how to do a task without getting immediate feedback on how the receiver is understanding the communication, one can expect that natural language instructions will be missing critical information -- or may also specify unneeded extra information. Ever since I worked in the IBM Speech Research Group circa 2000, I have felt natural speech could be useful in programming -- but it will take a different perspective on how to use natural language as conversation and related creative experimentation to provide a different experience compared to what people are used to doing with conventional programming languages. It might be more akin to some aspects of pair programming perhaps. That said, a big feature of HyperTalk (used by HyperCard) was that is is closer to natural language than most programming languages. HyperTalk supported various alternate phrasings and also the use of the word "it". And the physical "card" metaphor provided an approachable metaphor for instructions about manipulating stacks. It is sad that Apple essentially killed off HyperCard for most users with various marketing decisions as it was an amazing platform that made programming approachable for many non-programmers. https://en.wikipedia.org/wiki/HyperTalk And Inform7 as mentioned by someone else here is another example. Although Inform7 feels more about being read as natural language (when you write is within strict limits) than about being written flexibly as natural language.
自然语言适合交流，不适合精确描述；详细规格需要可视化或形式化。
啊，这就是 Dijkstra——编程很难，程序员就该受苦。不过他说得对：自然语言用于交流，而不是描述。当我们真的需要详细描述某事物时，得靠可视化或形式化。
Animats查看英文原文
Ah, that's Dijkstra - programming is hard and programmers should suffer. He's right, though. Natural language is for communicating, not describing. When we really need to describe something detailed, we need either visuals or formalism.
历次讨论
同类还值得读
开源应用架构
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编辑精选