编程与软件工程queue.acm.org
“大部分函数式”编程行不通
“Mostly functional” programming does not work
2014 — 2016，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇 ACM Queue 文章批评“半函数式”编程——在命令式语言里混入函数式特性——的做法，认为这种折中既得不到纯函数式的可推理性和安全性，又引入了额外的复杂度，实际效果不佳。文章以 C# 等语言为例，指出混合范式带来的陷阱，并主张要么彻底拥抱纯函数式，要么承认命令式的现实。
为什么经久不衰：它触及了“多范式混合 vs 纯范式”这一至今仍在争论的核心问题，多年间反复登上 HN 首页，是理解函数式编程落地之争的经典文本。
HN 评论精选
多范式混合恰恰是优点而非缺陷，关键是各范式用在刀刃上
我认为“半函数式”其实才是最佳平衡点。走向任何极端都会让某些事情变得极其困难。最优做法是在同一代码库中让多种范式共存，各用在最合适的地方。我会尽量用不可变数据和纯函数来写核心逻辑，但在需要 UI 等场景时切换到命令式或面向对象——UI 本质上就是 I/O，事件循环天然是命令式的。
yason查看英文原文
I think that "Mostly functional" is actually the sweet spot. Going to any extreme makes some things horribly difficult and going to another does the same for other things. So, optimally, multiple paradigms coexist in the single codebase, applied where they're most useful. Functional programming with as many immutable bits as possible is definitely a good start. I generally do that for whatever problem I'm solving: I have a model for the data and then I write (if at all possible) pure functions to transform the inputs into meaningful outputs. But then you need know where to drop the ball and move over to some other paradigm that does something else right and merely drives the functional parts from the top level. For example, such a data analysis library can be written with minimal state and using only pure functions but if -- and when -- you need some sort of an user interface so that the program can actually be used, an imperative/procedural approach is generally the most native approach because UIs are basically I/O. If you're adding a graphical user interface, you might use object oriented approach to build the UI tree which is probably the world's most idiomatic, canonical use for OO anyway. But even those are generally driven with an innately imperative event loop. Also, note that the different approaches or paradigms aren't language specific either. In the first stage, languages are tools that shape your thinking into accepting new programming paradigms but at some point you have a number of different ways of thinking in your head, and you can just forget about the languages they came from. But in the second stage, you can just think directly in paradigms: you can consider different ways to build different parts of your program but you might actually use only one language to implement everything. You can write functional, imperative, object-oriented, and whatever code in C. Or you can use several languages with strengths in each paradigm, depending on what trade-offs produce the best engineering in each case.
单子只是显式化副作用而非解决复杂性，应当正面拥抱状态
调试函数式程序非常困难（数据流调试器基本不存在），所以等式推理才是必需的。但把列表推导式和副作用混在一起确实是坏主意，我们 C# 程序员完全能避免它。不用单子也有驯服副作用的方法，单子其实并没有解决复杂性问题，只是把副作用显式化了。我们不该把状态当作不得已的恶，而应该拥抱它、处理它。
seanmcdirmid查看英文原文
Debugging a functional program is so difficult (data flow debuggers don't really exist) that equational reasoning is necessary because you want be able to fix your code otherwise. But really, mixing list comprehensions with effects is really a bad idea, and we C# programmers have no trouble avoiding it. There are ways to tame side effects without going monads, which don't really fix the complexity problem anyways (it just makes all effects explicit). See this paper for ideas on how to do that: http://research.microsoft.com/pubs/211297/managedtime.pdf We shouldn't treat state like an unwanted but necessary evil, we should embrace it and deal with it.
半函数式已带来实际收益，文章的批评为时过早
我不同意文章的部分观点：半函数式编程远比深度非函数式的代码效果好，而且越函数式收益越大。副作用可以互相模拟并不意味着程序员真的会那么做。编程风格更多被一些琐碎的不便（语法、库的可用性）塑造。一门仅仅劝阻人们写面条代码的语言，就应该能减少面条代码。现有 OOP 语言向函数式靠拢还远没到过度膨胀的程度，现在谈“半函数式不行”为时过早。
Kutta查看英文原文
I disagree with some of the sentiment expressed in the article; mostly functional programming works much better than profoundly non-functional code, and more functional programming usually delivers marginal benefits. The fact that effects can be used to simulate other effects does not imply that programmers would typically try doing that. In fact, programming style is more often shaped by trivial inconveniences (often syntactic, or the availability of certain libraries) than most of us care to admit. A programming language that merely discourages people from writing spaghetti code should still cause less spaghetti code being written. Freak bugs will pop up from time to time, but not as often. Shifting an existing language to a more functional style should be a net negative thing only if the resulting extra complexity and bloat gets excessive. Starting from an OOP/imperative position, it gets harder and harder to support an additional (marginal) piece of FP functionality, and after a while it's just better to start over and switch to pure FP, but current OOP languages flirting with FP are not particularly close to that point. They haven't started in earnest to introduce purity to an impure core language (which would be rather awkward, as the article points out). In this situation it is somewhat early to talk about mostly functional programming not working. Scala might be closest to the point of excessive bloat, but I'm not really familiar with it, and I think that the FP support there is a good thing, especially in contrast to the Java code that it might displace. (Disclaimer: I program chiefly in Haskell and I love it).
C++ 的历史教训表明“中间道路”式语言混合往往导致复杂度爆炸
软件工程界正面临重蹈二十年前对象覆辙的危险。当年 C++ 被宣传为“中间道路”，让你“为工作选最好的工具”，结果 OO 特性与既有结构化特性无法良好契合，导致规则组合爆炸，老程序员写出的往往是撒了几个虚函数的传统结构化设计。今天函数式与命令式混合的故事如出一辙。
PaulAJ查看英文原文
The software engineering world is in danger of repeating the mistake it made with objects two decades ago. Back then there were legacy "structured" languages like C and Ada, and new exciting "object oriented" languages like Smalltalk and Eiffel. C++ was promoted as a "middle way" that let you "choose the best tool for the job". This made the pure OO languages look extremist. So, it was argued, if you had a problem best solved by structured programming you could do that, and if you were doing an application with objects in it then you could use those. It also meant that your old C programmers could pick up the tool and start using it immediately without having to relearn how to design a program. "Aversion to Extremes" is a well-known cognitive bias, and these arguments play up to it, but of course it didn't work well in practice. OO features didn't dovetail neatly with the existing structured features, leading to an exponential explosion in the rules defining how the various features interacted. The mess was not helped by experienced structured programmers who felt they should use the new sexy OO features; the result was often a conventional structured design with some random virtual functions sprinkled around. The book "Industrial Strength C++" is a case in point. It is basically a catalogue of C++ language features that interact in dangerous ways. http://www.amazon.com/Industrial-Strength-Recommendations-Innovative-Technology/dp/0131209655 Today we have the same story happening again. On one hand we have legacy OO languages like Java and C++, and on the other hand we have pure functional languages like Scheme and Haskell. So along come "hybrid functional" languages like Scala which basically make the same promise as C++: if your problem has lots of objects then you can carry on doing the same OO designs you know and love, but if you think that these magic first-class functions would be useful in some complicated algorithms then you can use those as well. And its going to fail for the same reasons that C++ failed: the OO and functional features don't interact well, so we are going to have lots of messy rules about them that cause subtle bugs, along with attempts by OO programmers to use chains of map and filter functions that work inefficiently because the compiler can't optimise them. And in ten years time there will be an "Industrial Strength Scala" book consisting of a long list of features that should be avoided if you want reliable software.
命令式已有巨大实践成果，半函数式是在其上做增量改进，完全可行
考虑到：1) 半命令式编程多年来成果斐然，几乎所有基础设施、主流操作系统和流行程序都用 C/C++/Java 等写成；2) “纯函数式”虽有安全保证，但历史上拿不出多少重要成果。我要说，“半函数式”其实运行得很好——它在已经有效的命令式基础上，加一点函数式让它变得更好。
coldtea查看英文原文
Condidering that 1) mostly imperative programming has worked wonders for ages with a huge body of work to show for (almost every basic infrastrcuture, all major OSes, almost all popular programs etc are writen in one of C/C++/Pascal/Obj-C/Fortran/Ada/Java). Might have its security and stability warts, but it has shown pragmatic results. 2) "fully functional" might have its security and stability assurances, but it has little of importance historically to show for all its boasting (the AI winter is not something to be really proud of). I'd call BS, and say that "mostly functional" works fine, thank you very much, in that it takes (1) that already works (with some issues) and makes it even better with a touch of (2).
文章用稻草人论证贬低 C#，其“改用 Haskell”的方案不切实际
按文章的说法，我这些年做的事都“不工作”？C# 开发者大多用 Visual Studio，拥有世界上最好用的调试器之一，并不靠 printf 调试。用 LINQ 的人就是明确想要延迟执行。文章立了一堆 C# 的稻草人，而它给出的解决方案竟是……用 Haskell 重写整个世界？我总不能说服所有利益相关者迁移到 Haskell，还失去我依赖的所有库。
moron4hire查看英文原文
Well now, what the hell have I been doing all this time? According to TFA, apparently nothing that "works". If you're working in C#, you're most likely working in Visual Studio (Mono is just such a terrifically small proportion of C# users, and even then, some Mono users are using Visual Studio), so you have access to one of the best (and easiest to use!) debuggers in the world. This isn't embedded C++. It is common for .NET developers to know how to use the debugger. People don't use printf-style debugging, and even if they thought they would want to, there is no easy way for such an undertrained developer to do it. You have to make a special build to get the "console" window, and it's a setting most developers I've encountered just plain don't even know exists. And if you're using LINQ, it's because you know you want deferred execution and that's explicitly what you're hoping for. Developers who don't know this feature/limitation of LINQ just plain don't know about LINQ. So after all these C# strawmen, his proposed solution is... rewrite your entire world in Haskell. Yeah, that's totally going to happen. I'm going to get my stakeholders on board for that, I'm going to have all of the libraries I've come to love available to me, or reasonable analogues (Just looked at HDBC, it looks like a toy compared to ADO.NET). We're just going to switch to Haskell and everything is going to be peaches and cream.
历次讨论
同类还值得读
开源应用架构
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编辑精选