编程语言与软件工程2016worrydream.com编辑精选
程序设计能否摆脱冯·诺依曼风格？(1977)
Can Programming Be Liberated From The Von Neumann Style? (1977)
进阶 · 约 75 分钟读完前置知识：编程语言基础、函数式编程概念、基本代数/组合思想
导读
这是 Backus 1977 年的图灵奖演讲，质疑以「逐字赋值、修改存储」为核心的冯·诺依曼式编程风格，主张用函数式编程（FP）与「组合形式」（combining forms）把程序组织成代数式的函数复合，从而摆脱对逐个字状态更新的依赖。文章既是编程范式批评，也给出了一个函数式语言的设计草案。
HN 关注点：HN 读者围绕「近 50 年后编程是否真的摆脱了冯·诺依曼风格」展开讨论：有人认为 GPU、声明式/逻辑编程已经部分实现，也有人质疑任何 1960 年代的替代方案都未必更优。
后来怎么样
这篇图灵奖演讲成为函数式编程的经典文献，推动了函数式思想进入后续语言设计与程序代数研究；不过其提出的 FP 语言与组合形式本身并未成为主流编程模型。
HN 评论精选
这几条评论里：支持 1 补充 2 亲历 1
补充当年性能增长让替代架构缺乏竞争力，真正的范式转变正在靠 GPU 等新硬件发生，而非单纯否定冯·诺依曼。
答案是「在计算性能每年指数级增长的时候还不行」——这种改进曲线实在太难对抗了。而现在它正在被解放：GPU 已经大量部署，架构与冯·诺依曼根本不同，各种替代方案也在酝酿。不过我并不认为我们当年是卡在「冯·诺依曼」本身，换成 1960 年代定下的任何东西我们大概都会卡住。而且尽管熟悉会生轻视，我也不太相信我们在 60 年代能做得更好多少：很多替代方案并非普遍更优，只是在特定领域更好，未必能全面战胜冯·诺依曼，哪怕考虑到「通用计算」已经和冯·诺依曼共同演化了 50 年。
jerf查看英文原文
The answer was "not while computing was getting exponentially better every year". This sort of improvement curve is really difficult to compete with. It's in the process of being liberated now. GPUs are already deployed in many machines with a fundamentally different architecture. And there's a bubbling foment of alternatives being developed now. In the end, I don't think it was necessarily a case of us getting stuck on "von Neumann" per se... we would have gotten stuck on anything we settled on in the 1960s. And despite familiarity breeding contempt, I'm not that convinced we could have done that much better in the 1960s. A lot of the alternatives are not universally better, they're better in some limited domain but it's not obvious that they are going to uniformly beat von Neumann for general computing, even accounting for the fact that "general computing" has coevolved for 50 years with von Neumann. See also https://news.ycombinator.com/item?id=12155561 (which may well have been the inspiration for this submission)
亲历逻辑/声明式编程已经实现了这种解放，只是需要开发者改掉冯·诺依曼式的思维习惯。
其实它早就被解放了，只是不太流行——这正是 Prolog 让大多数人头疼的原因。我学 Prolog 时的顿悟时刻，是意识到自己并不是在讲逻辑，而是在用冯·诺依曼风格解题。看到简单的逻辑解法取代我那些过度复杂的解法，我很受触动。这让我成了更好的开发者，现在尽量让代码保持声明式。
segmondy查看英文原文
It already has, unfortunately it's not too popular. This is why Prolog gives most folks a case of headache. My moment of enlightenment while studying Prolog happened when I realized that I wasn't logical, but trying to solve the problem in Von Neumann style. I was humbled to see simple logic solutions in place of my overly complicated solutions. This has made me such a better developer, I keep my code as declarative as possible.
补充补充历史轶事：冯·诺依曼曾反对 Fortran，两人关注点不同——一个追求解题，一个关心编程成本与易用性。
Backus 和冯·诺依曼在 IBM 时期就有渊源。Backus 最初向老板提出 Fortran 时，首先「必须克服当时担任 IBM 顾问的冯·诺依曼的有力反对」。用 Backus 的话说：「他不认为编程是个大问题。我认为他的主要反对理由之一是，用浮点计算你不知道自己会得到什么；而定点运算至少出了问题你知道问题在哪。但他对编程成本不敏感，他真的觉得 Fortran 是白费力气。」Backus 和冯·诺依曼分别在浮点和定点数字的计算机应用上做出创新。据我所知，冯·诺依曼是那种不断推出新想法的天才，他引入「比例因子」（定点）解决核物理中的科学问题，并不操心提升其「易用性」；而 Backus 关心编程的困难——Fortran、浮点工作以及后来的函数式编程努力都体现了这一点。离开计算领域后，Backus 转向冥想和他所称的「生活」。
gavinpc查看英文原文
Backus and von Neumann have a history, from their time at IBM. When Backus first proposed the idea of Fortran to his boss, he first "had to overcome the persuasive arguments of von Neumann, who was then a consultant to IBM." In Backus' words: > He didn't see programming as a big problem. I think one of his major objections is that you wouldn't know what you were getting with floating point calculations. You at least knew where trouble was with fixed point if there was trouble. But he wasn't sensitive to the issue of the cost of programming. He really felt that Fortran was a wasted effort.[0] Backus and von Neumann had made innovations in the use of floating-point and fixed-point numbers by computers, respectively. From what I can gather, von Neumann was an incredible genius who just continuously pushed new ideas. He introduced "scaling factors" (fixed point) to solve a scientific problem (in nuclear physics) and didn't worry about improving its "usability." Backus, on the other hand, cared about the difficulty of programming. Both Fortran and his work on floating-point, as well as his later efforts in functional programming, manifested that. After leaving computing altogether, Backus took to meditation and, as he calls it, "living." [0] Quotes are from chapter 1 of Out of Their Minds: the Lives and Discoveries of 15 Great Computer Scientists, by Shasha and Lazere.
支持AI 研究长期受「大脑≈冯·诺依曼机」的隐喻误导，需要更根本的架构突破。
我认为放弃冯·诺依曼范式对 AI 至关重要。几十年来我们一直误以为大脑同构于冯·诺依曼架构，有「内存库」和「处理单元」，而这条路失败了。诚然 Lisp 曾是 AI 研究的首选，也没能把我们带进应许之地。也许函数式方法还不够激进 :)
nemo1618查看英文原文
I think abandonment of the Von Neumann paradigm will be crucial for AI. For decades we have labored under the misguided assumption that the brain is isomorphic to the Von Neumann architecture, with "memory banks" and "processing units." This approach has failed. Admittedly, Lisp was once the first choice for AI research, and it did not readily lead us into the promised land either. Perhaps a functional approach is not radical enough :)
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2016Hacker News 讨论帖202 分 · 175 评
同领域还值得读
Google 的软件工程（2017）
Software Engineering at Google (2017)
介绍了 Google 的软件工程实践，包括其单一代码库（monorepo）、几乎全部开发在主干进行而非分支、代码审查、构建系统 Blaze、协议缓冲区等工具与流程，并讨论了频繁重…
编程语言与软件工程2017 · 1,127 分 · 465 评 · 引用 15入门 · 约 45 分钟编辑精选Peter Naur：编程作为理论构建 (1985)
Peter Naur – Programming as Theory Building (1985)
Peter Naur 1985 年的经典论文《Programming as Theory Building》提出：编程的本质不是写代码或文档，而是在程序员头脑中构建对程序及其运行…
编程语言与软件工程2016 · 629 分 · 74 评入门 · 约 45 分钟编辑精选SciPy 1.0：Python 科学计算的基础算法
SciPy 1.0: fundamental algorithms for scientific computing in Python
这篇发表于 Nature Methods 的论文介绍了 SciPy 1.0——Python 科学计算生态的基石库，涵盖其核心算法模块（优化、积分、插值、线性代数等）、软件架构与社…
编程语言与软件工程2020 · 387 分 · 98 评入门 · 约 45 分钟编辑精选Lisp 的历史（1979）
History of Lisp (1979)
这是 Lisp 发明者 John McCarthy 于 1979 年为 HOPL（编程语言史）会议撰写的回顾文章，讲述 Lisp 的起源、设计动机与早期演进，文中也涉及 if 表…
编程语言与软件工程2018 · 352 分 · 44 评入门 · 约 45 分钟编辑精选使用 NumPy 进行数组编程
Array Programming with NumPy
这篇 Nature 文章介绍 NumPy 的数组编程模型及其在科学计算中的核心作用：以 ndarray 为中心，通过向量化操作让 Python 高效处理多维数组。
编程语言与软件工程2020 · 318 分 · 134 评入门 · 约 40 分钟编辑精选