编程与软件工程blog.ploeh.dk
从设计模式到范畴论
From Design Patterns to Category Theory (2017)
2017 — 2019，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 Mark Seemann 博客系列的开篇，作者认为许多面向对象的设计模式（如 Visitor、Decorator 等）本质上是范畴论中单子、幺半群等概念的临时、非形式化的特例，并计划逐篇用范畴论语言重新阐释设计模式。文章引发了关于设计模式与抽象代数、范畴论之间关系的广泛讨论。
为什么经久不衰：它把 OOP 世界熟悉的'设计模式'与函数式编程背后的数学结构联系起来，为 OO 程序员理解 FP 提供了一座桥梁，多年后仍是这一话题的经典入门读物。
HN 评论精选
作者本人从 OO 转向 FP 的经历使这个系列格外有说服力和可读性
我从这个系列开写就一直在追。Mark Seemann 起初是深度面向对象的程序员，写过优秀的《.NET 依赖注入》，后来接触 F# 再到 Haskell 并持续写博客。他的博客档案记录了一位顶尖 OO 程序员演变为严肃函数式编程倡导者的全过程，而且他非常擅长向 OO 程序员解释 FP 的价值。
bunderbunder查看英文原文
I've been following this series since the author started it. For context, when I first became aware of the Mark Seemann, he was very deep into the object-oriented way of doing things. I discovered him because he was the author of (the excellent) Dependency Injection in .NET. A while after writing that book, he started getting into F#, and eventually Haskell, and blogged about it all the while. The upshot being, his blog archive now tells a fascinating story of the evolution of one person from being a an extremely accomplished object-oriented programmer toward being a serious functional programming advocate. He's also done a very good job of explaining what FP has to offer to an object-oriented programmer, or at least one who likes a certain style of OOP. For example, see https://blog.ploeh.dk/2017/01/27/from-dependency-injection-to-dependency-rejection/
设计模式确实对应代数结构，但'范畴论'这个标题选错了，抽象代数/泛代数才是更贴切的框架
我多年来一直说设计模式是被模糊看到的代数结构（现在我会加上'加不变式'）。但用范畴论作标题并不合适：范畴论关注的是把多个代数放入同一空间并研究它们之间的映射，源于代数拓扑。文中许多结构其实更早出现在抽象代数或泛代数（幺半群、格）或组合数学（ magma）中，而范畴论视角往往反而不便，格直接用满足公理的集合加运算来处理更简单。
madhadron查看英文原文
I've been saying for a few years that design patterns are algebras seen dimly. People have asked me for references for that, and I haven't had anything to point them to. At this point I would modify it as algebras plus invariants. I would say category theory is the wrong title for this, though. Category theory is occupied with the algebras that emerge when you put algebras into the same space and look at mappings among them. It emerged in algebraic topology where you would construct a family of algebras that describe aspects of a geometric structure and then establish connections among them to talk about the effects of operations on those geometric structures. Categories gave you one algebra, functors gave you families of algebras, and natural transformations gave you operations on the underlying spaces. Many of the algebras described here and others that I have found useful emerged earlier in abstract algebra or universal algebra (monoids, lattices) or in parallel in combinatorics (magmas). The category theoretic view is often an inconvenient setting. Lattices, for example, are best dealt with simply as a set with some operations that obey specific axioms. You get theorems from the axioms, and if you need one of those theorems to apply to your system, you make sure you implement it in such a way that it obeys those axioms. Or if you have an algebra near to what you need, you may be able to modify it in the abstract setting to keep properties that you want. I ended up doing this with lattices to describe tagging regions of genomes.
批评作者把范畴论泛化为'形式数学'，认为实践中根本不需要它，过度抽象是 FP 的通病
作者犯了函数式程序员常见的错误：把'范畴论'当作'形式化数学语言'的同义词，这通常是因为他们通过 Haskell 的 monad 第一次接触范畴论。放心，成为高效的函数式程序员完全不需要范畴论，连 monad 也不需要。在只有一个具体案例时追逐更高抽象，就像用变分法求三角形面积，是函数式版的'OO 架构宇航员'。
fjsolwmv查看英文原文
The author appears to making the common functional programmer mistake of using "Category thoeory" to mean "formal mathematical language", likely because they usually encounter category theory for the first time when they see Haskell's "monad", shortly before they see all the Haskell typeclasses named for other non-category-specific algebraic objects like monoids and morphisms. Rest assured, you absolutely do not need any category theory to be an effective functional programmer. Everything is a category because category theory is the most general formulation of algebra. But you don't need to know categories for any of it. Not even for monads. It's like trying to use calculus of variationsnto find the area of a triangle. You can so it, but it's pointlessly overcomplicated overengineering. Chasing after ever-higher abstractions when you only have one concrete case to abstract over, is the functional programmer's version of OO architecture astronautry.
形式化的价值在于能带来原本写不出的代码，文章只做了'重新命名'而没展示这种增量
这种思路有一个未被正视的缺陷：临时、非形式化的东西之所以 informal，是因为它遗漏了某些内容。如果形式化真的有价值，就应该存在一些情形，额外的抽象能让你写出原本写不出的更好代码。而这篇文章只是展示你本来就会写的东西，再用更一般的术语描述它，那些'你原本不会写的东西'恰恰缺失了。比如某些 monad 教程里的非确定性选择 monad 练习，就是你不会自己想到去写的东西，这才真正展示了 monad 概念的用处。
conistonwater查看英文原文
> It seems to me that some design patterns are essentially ad-hoc, informally specified, specialised instances of basic category theory concepts. There is a flaw in this type of thinking which I think is not addressed here, but should be. (I took the quote from the summary, but I think it's fair.) The usual issue with ad-hoc informally specified things is that the ad-hocness and the informality leaves something out, making sure that if you understand the informal thing, but not the formal, you end up understanding only some part of the whole thing that you could understand if you tried. So in the context of design patterns, that means there should exist situations where the extra abstraction, the non-ad-hoc non-specialized understanding, allows you to write code that is better than otherwise, and (more importantly) that you would not have otherwise written. This would show explicitly the gap between the ad-hoc ideas and the formal ideas instead of leaving you to guess. Whereas the way this post tries to explain it, as I understand it, is that it shows you things (design patterns) that you would have otherwise written, and shows how it can be talked about in more general terms. But the things that you wouldn't have written are missing. E.g., in some monad tutorials at some point one of the exercises is the nondeterministic choice monad, which is totally something you might not have written yourself, which makes it a way of showing why monads are a useful concept. If the only monad you had was IO, it'd be a much more useless idea (it would merely be a different, not even necessarily better, way of writing things that you already knew).
历次讨论
同类还值得读
开源应用架构
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编辑精选