编程与软件工程conal.net
函数式编程能否摆脱冯·诺依曼范式？（2010）
Can functional programming be liberated from the von Neumann paradigm? (2010)
2010 — 2018，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
Conal Elliott 的文章追问：函数式编程能否真正摆脱冯·诺依曼式、以状态和指令为中心的编程模型，还是底层仍不可避免地带有命令式核心。文章更像提出问题和表达希望，而非给出定论；评论则围绕纯函数式与多范式、I/O、时间、状态处理以及错误处理等现实约束展开。
为什么经久不衰：因为它把“纯函数式是否只是理想”这一根本争论摆上台面，而评论中关于 I/O、状态和多范式取舍的讨论至今仍是工程实践的核心。
HN 评论精选
实际软件应采用多范式，在 I/O 边界用命令式驱动、内部用函数式，纯度不应成为教条。
如果你打算固守一种范式并保持纯粹，这个问题才成立；就任何实际用途而言，那没什么用。用函数式方式写程序主旨、保持不可变、允许无序执行和惰性求值都没问题。但程序要与真实、有后果的世界交互，就必须在 I/O 的枢纽点完成计算，这时惰性求值是否完成突然变得重要。可以用过程式循环驱动事件和其他实用事务，再从那里启动函数式计算，算出程序全部或部分新状态。让大部分东西不可变，但在特定合理位置做变更。Clojure 擅长让程序员按自己觉得合适的地方划线。多范式在交付真正可用、又不必让程序员为纯粹性做脑力体操的程序上，总是完胜纯意识形态。你不想整个程序都用面向对象、过程式、函数式、声明式或你偏爱的任何范式；它们各有擅长和不擅长，要像工具一样，合适工具做合适事。
yason查看英文原文
The question is valid if you intend to stick with one paradigm and keep it pure. For any practical purposes, that's useless crap. Nothing wrong with writing the gist of your program written in functional way, keeping things immutable, allowing for orderless execution and lazy evaluation. But because your program interfaces with the real, consequential world it must realise all that computation at the pivot points where there is I/O and it suddenly matters that the lazy evaluation is complete. Have a procedural loop to drive your events and other practical stuff and, from there, launch functional computations to calculate a completely or partially new state for your program. Keep things mostly immutable but do mutation in certain specific locations where it makes sense. Clojure is good at drawing the line where the programmer sees it fit best. Multi-paradigm has always beaten pure ideologies hands down when it comes to delivering useful programs that actually work without making programmers do mental gymnastics for the sake of purity. (They should reserve their efforts to be mentally gymnast in the real-world problem they're solving.) You don't want to write all of your program in object-oriented, procedural, functional, declarative, or whatever paradigm you have a thing for. They all do some things well and suck at others. Use them like tools, the right one for the right job.
文章更像宣言；命令式核心是否不可避免仍无定论。
这篇文章很难评价：它更像一种希望或宣言，而不是我能具体回应的论证。它认为我们的编程模型中存在不可消除的命令式核心只是一种假设，我同意。但这不说明该假设对或错，只是要等证明或证伪。人们应继续尝试证伪它，但我不能责怪多数开发者继续把它当作假设。
hyperpape查看英文原文
This piece is hard to evaluate: it seems more like an expression of hope or a manifesto than something I can engage with. It argues that the idea that there is an ineleminable imperative core in our programming model is just an assumption today, and I agree. But that doesn’t mean it’s right or wrong, just that we have to wait to prove or disprove that assumption. People should keep trying to disprove it, but I can’t fault the majority of developers for continuing to take it as an assumption.
Clojure/Datomic 把时间与 I/O 当作一等问题；真实系统不存在绝对纯粹。
理解和建模 I/O 是 Clojure 流行的重要原因。它函数式、近乎纯粹，但内建了对时间、并发和 I/O 的理解。做 I/O 时时间很重要，可以看看 Datomic 如何增量地建模。Rich Hickey 早说过不存在纯函数系统，甚至空硬盘也会发热，这是一种 I/O；我们该听 Hitchens 的，放弃写真实软件时的“纯度幻想”。
lbj查看英文原文
Understanding and modelling IO is a big part of why Clojure took of like it did. Its functional, its pure-ish but it has an understanding of time, concurrency and IO baked in. When you do IO time matters, take a look at how Datomic models this (incrementally). But even from the early days, Rich Hickey said that no pure functional system exists as even an empty HD emits heat, which is a form of IO and I think we should listen to Hitchens and abandon our "fantasy of purity" when it comes to writing real software.
FP 的困难常来自内存、错误处理和可恢复性等现实约束；局部状态可合理使用而不破坏纯粹性。
值得注意的是，函数式编程难不是因为函数式范式本身，而是解决问题时的约束（比如内存）。这要求把可永久复用的简单可组合函数，改成必须分多阶段工作的复杂函数。另一个与问题本身无关的固有复杂性来源，是输入或运行时问题的处理。输入不能保证始终一致，运行时也可能出问题（用户中断）。这时中断计算容易，但用户可能想：知道函数为什么停止并有意义的答案（不只是栈回溯）；知道错误在输入数据中的位置；能恢复计算。如果你写过函数式程序，就知道在 fold/map 调用链里给出有意义的错误信息有多难。保持状态是应对这个反复出现问题的简单（也可说同样优雅）方案。请注意我是从函数式编程角度说：对象作为局部状态容器未必破坏纯粹性。另一个问题是我们人类基于有状态世界；有状态用户界面有时更高效……
tenfingers查看英文原文
It's worth nothing that functional programming is hard not because of the functional paradigm, but due to the constraints you have while solving a problem (memory, for one). This requires changing the simple, composable functions that you could reuse forever, to complex ones that have to split the work into multiple stages. Another source of inherent complexity which has nothing to do with the solution of the problem itself, is the handling of the input or runtime issues. Input cannot be guaranteed to be always coherent, and runtime issues may arise while running (user interrupt). At this point, interrupting the computation is easy, but as an user I want maybe: * know why the function stopped, with a meaning answer (not just a stack trace) * know the location of the error in the input data * the possibility to resume the computation If you've ever programmed functionally, you know how hard is to do something as simple as give meaningful error messages buried into a series of fold/map calls. Keeping state is a simple (and I would say equally elegant) solution to this recurrent problem. Please consider that I'm saying this from a functional programming perspective (as in: objects as localized state containers not necessarily breaking the purity assumption). Another issue is that we, as humans, are based on a stateful world. Stateful user interfaces are sometimes more efficient due to the way _we_ work. This can be seen in something as simple as "now select a file", which brings up a dedicated section of stateful code to navigate a tree. As such, you are constantly faced with the problem of keeping state.
历次讨论
同类还值得读
开源应用架构
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编辑精选