编程与软件工程gamasutra.com
C++ 中的函数式编程（2012）
Functional programming in C++ (2012)
2014 — 2020，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 John Carmack 2012 年发表的长文，探讨如何在 C++ 中采用函数式编程风格。他结合游戏开发经验指出，大量软件缺陷源于程序员未能完全理解代码可能处于的所有状态，而函数式风格让状态显式化、更易推理，在纯函数系统中甚至能消除线程竞态。他建议无论用什么语言，只要方便就应尽量以函数式风格编程。
为什么经久不衰：Carmack 把函数式编程从语言之争中剥离出来，落到多线程与状态管理的实际工程问题上，这篇经验之谈至今仍是理解该话题的最佳入门之一。
HN 评论精选
概括了 Carmack 的核心论点：显式化状态、便于推理、消除竞态
他提出的核心观点：软件开发中很大一部分缺陷源于程序员没有完全理解代码可能执行到的所有状态；在多线程环境下，这种理解缺失及其带来的问题会被急剧放大。以函数式风格编程能让代码面对的状态显式化，从而更容易推理，在完全纯函数的系统中甚至使线程竞态成为不可能。无论你用什么语言，函数式风格都有好处，方便时就该用，不方便时也应认真权衡。
pmarreck查看英文原文
The key points he makes: "My pragmatic summary: A large fraction of the flaws in software development are due to programmers not fully understanding all the possible states their code may execute in. In a multithreaded environment, the lack of understanding and the resulting problems are greatly amplified, almost to the point of panic if you are paying attention. Programming in a functional style makes the state presented to your code explicit, which makes it much easier to reason about, and, in a completely pure system, makes thread race conditions impossible. "No matter what language you work in, programming in a functional style provides benefits. You should do it whenever it is convenient, and you should think hard about the decision when it isn't convenient."
函数式语言的简洁性来自语法特性而非纯函数本身；C++ 缺少函数式数据结构是痛点
函数式语言程序有时更简洁的那些因素——垃圾回收、强大的内置类型、模式匹配、列表推导、函数组合、各种语法糖等——与纯函数的使用基本无关。这些'缩减代码量的因素'大多与函数式无关，在一些命令式语言里也能找到。我认为函数式编程新手会被这一点搞糊涂，而一些老牌拥护者则把这些因素当成了函数式定义的一部分。另外：C++ 有广泛可用的函数式数据结构吗？没有它们的话，函数式编程代价很高——Clojure 若没有采用 Bagwell 的数据结构思想，也不会那么有吸引力。
FPGAhacker查看英文原文
Quote > The factors that allow programs in functional languages to sometimes be more concise than imperative implementations are pretty much orthogonal to the use of pure functions — garbage collection, powerful built-in types, pattern matching, list comprehensions, function composition, various bits of syntactic sugar, etc. For the most part, these size reducers don't have much to do with being functional, and can also be found in some imperative languages. — Amen. I think people new to functional programming are thrown by this, and I think some long time adherents of functional programming have adopted these “factors” as part of the definition. Definitions change, that’s fine, but the confusion of ideas isn’t good. Anyway, are there functional data structures widely available to c++? I assume there are. Without them, functional programming has a heavy cost. Clojure, for one, would not be very attractive without having adopted Bagwell’s data structure concepts.
纯函数只是抽象，执行仍有成本，React 滥用纯渲染函数就是反面教材
纯函数只看传入的参数，只返回基于参数计算出的值，没有逻辑上的副作用——这当然是一种抽象；每个函数在 CPU 层面都有副作用，大多数在堆层面也有，但这个抽象仍然有价值。重读多次后，这次让我印象最深的就是这段，尤其是后半句。现实中不存在真正的'纯'函数，因为执行总要付出代价。某些函数式程序员把这个概念曲解成纯函数是免费的、可以无限次执行。这种极端想法的一个后果就是如今的 React.js：大多数 React 应用病态地过度执行我们用来定义组件的'纯'渲染函数，导致性能下降、GC 压力增大。能多次调用纯函数不代表你应该这么做。
bikeshaving查看英文原文
> A pure function only looks at the parameters passed in to it, and all it does is return one or more computed values based on the parameters. It has no logical side effects. This is an abstraction of course; every function has side effects at the CPU level, and most at the heap level, but the abstraction is still valuable. Rereading this for the umpteenth time, this is the paragraph which sticks out to me this time around, and a point which I think most people miss, specifically the latter part about “pure” functions consuming CPU and memory. The reality is that there is no such thing as a “pure” function, insofar as execution of that function costs something. Certain functional programmers corrupted this idea to somehow mean pure functions are free; that these functions can be executed one to infinity times and the result is the same. For instance, this idea taken to an extreme has resulted in the current situation with React.js, where most React applications pathologically over-execute the “pure” rendering functions which we use to define components, resulting in degraded performance, increased GC pressure, and a lack of understanding of how our code executes. Just because you can call a pure function many times doesn’t mean you should.
这句话在 OOP 和微服务时代更加切中要害
'软件开发中很大一部分缺陷源于程序员没有完全理解代码可能执行到的所有状态'——我在日常编程中经常想起这句话。面向对象编程充满了有状态的对象，程序员很容易给各种事件挂监听器；如今云端还有这么多微服务和触发函数，小小的改动就可能引发级联后果。
seanalltogether查看英文原文
> A large fraction of the flaws in software development are due to programmers not fully understanding all the possible states their code may execute in. I think about this quote often in my day to day programming. Object oriented programming is so full of stateful objects and it's easy for programmers to add listeners to all sorts of events. Even on the cloud side now you have all these micro services and trigger functions and small changes can have cascading consequences.
历次讨论
同类还值得读
开源应用架构
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编辑精选