编程与软件工程evanmiller.org
数学黑客
The Mathematical Hacker
2012 — 2019，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
Evan Miller 的这篇文章讨论程序员与数学的关系：它批评那种认为写代码用不上多少数学的观点（文中以 Eric S. Raymond 为代表），并把编程社区粗略分为偏重递归与形式逻辑的“Lisp 学派”和偏重数值计算、应用数学的“Fortran 学派”。作者以斐波那契数列为例，说明数学知识往往比直接写递归函数更能解决问题，并主张应用数学对程序员正变得越来越重要。
为什么经久不衰：它正面回应了“程序员到底要不要学数学”这一长期争论，论点与斐波那契例子在此后多年仍被反复引用和辩驳，是讨论编程与数学关系的经典入口。
HN 评论精选
计算机科学本身就是数学，且程序员对编程语言研究的数学兴趣在增长，文章视野偏窄。
令我意外的是这篇文章写于 2012 年，读的时候我以为它至少有十年历史了。计算机科学研究者在做真正的数学，他们显然更属于文章所说的“Lisp 学派”而非“Fortran 学派”：函数式编程研究大多是数学——lambda 演算（最初根本不是为编程语言发明的）、类型、逻辑、范畴论……编程语言研究用的工具历来都是数学工具。文章很好，我大体同意结论，但它似乎忽略了计算机科学实际发生的大量事情。我理解它主要谈程序员而非计算机科学家，但“程序员不关心 CS 研究”越来越不成立：Lisp 发明了如今几乎所有语言都有的东西（条件表达式、垃圾回收、一等函数、一切皆表达式、递归……），花了很多年才普及；而今天程序员社区对 Haskell、Scala、OCaml 乃至 Coq、Isabelle 都有浓厚兴趣，要理解这些项目哪怕一点点，都得学（哪怕是间接地学）数学。
p4bl0查看英文原文
I find it disturbing that this article has been written in 2012. While I was reading it I really thought that it was at least 10 years old. Computer science researchers are doing actual mathematics, and they are clearly more in what the article calls "Lisp school" than the "Fortran school". Research in functional programming is mostly mathematics. Lambda calculi (which was originally not developed to be a programming language at all), types, logic, category theory… Most of the tools used in programming languages research are mathematical tools, and they always have been. The article is great and I mostly agree with its conclusion, but it seems to miss a lot about what is actually going on in computer science. I understand that it mainly talks about programmers and not computer scientists, but it's less and less true that programmers are not interested in what is happening in computer science research. Lisp invented a lot of the stuff that are now in almost every languages (conditionals, garbage collector, first class function, everything is an expression, recursion…) and it took many years to arrive here. But nowadays I see a lot of interests from the programmer community for what is happening in the programming languages research around Haskell, Scala, OCaml, and even stuff like Coq, Isabelle… ! In order to understand even a little what is actually going on with these research project one have to study (even if indirectly) mathematics. Now that I have written this comment, I'm thinking that may be I have a skewed/distorded vision and that I'm not really talking about the same people as the article does. I don't know.
论点成立，但人为制造 Lisp 与 Fortran 的对立，并无必要贬低函数式编程。
文章的问题在于虚构了一个并不存在的对立，然后用一个争议性叙事掩盖了本身很扎实的论点。如今很少有人不知道他提出的那些点，Yegge 和 Graham 也不是想象中“应用数学阵营”的反面——我倾向于认为他们是支持数学的（Yegge 对生物感兴趣，Graham 做过垃圾邮件相关的东西）。我试着概括其要点：程序员的数学不只限于类型论和形式逻辑，应用数学同样重要；Eric S. Raymond 把“除了 X”说成可忽略是错的；机器学习、生物、地理等领域的数学重要性在快速增长；过去应用数学软件也通过让工程师使用专用工具对经济产生了巨大影响。学数学，对未来的程序员很重要。另外我不明白他为何把函数式编程局限于 Lisp 的递归，没必要贬低它——它和应用数学问题非常契合，有助于降低实现复杂度，速度也至少与 Java 相当，OCaml 的单核速度惊人。
Dn_Ab查看英文原文
The problem with the article is that it dreams up a false conflict and then buries its thesis, a very valid and solid one, by trying to force a contentious narrative onto that just isn't there. Very few people these days are ignorant of the points he makes and neither Yegge nor Graham are posts of some imagined counter applied math camp. I would tend to think they are pro - Yegge's interested in bio, Graham did spam stuff. Here is my attempt at a summary that captures all the detail: Programmer math is not only restricted to type theory and formal logic. Applied Math is also a very important aspect. Eric S Raymond is wrong for trying to make it look like the 'Except for X' is negligible. Plus, machine learning, bio, geo and so on are increasing in importance and growing rapidly as fields. Even in the past, applied Math Programs had a massive impact on the economy by enabling engineers with specialized software. Learn Math. It is important for you as a programmer going forward. --------- I am not sure why he restricts functional programming to recursion with lisp. There is no need to denigrate functional programming, it fits extremely well with these applied math problems and helps a lot with reducing complexity of implementation, in my opinion. They also tend to be at least as fast as Java with OCaml posting incredible single core speeds. Another point is math algorithms is distinct from mathematical programming. Math helps one calculate and choose faster algorithms or find better bounds. But except for some portions of the haskell compiler there are few uses of direct calculation to derive programs mathematically. In engineering, math allows you to precisely calculate behaviour and properties but in programming you have to debug. The key reason for this divide is that other engineers have lots of components with well defined properties to work with. This is another reason why functional programming is more mathematical. Although the idea of composition is not inherent to FP, in FP it is the default paradigm. The ideas of combinators with well defined properties, and theorems proven on them, that only go together in a certain way and that you can sit down and have a pretty good idea of how your program would behave theoretically, this idea is what makes FP so close to doing applied math. And Haskellers really shine at that. Haskellers like to talk about monoids and categories but really most of haskell programming is closer to what a reguler engineer does with the category theoriests serving the same function as physicists.
斐波那契只是教学用的稻草人，换一组例子同一论点可以反过来支持 Lisp。
文章总体提出了很好的观点，但斐波那契例子有点弱，像个稻草人。函数式编程教程教递归斐波那契或阶乘，并不是为了教一个有用的函数，甚至不是可用的函数——它们往往还会展示 N 稍大时的糟糕性能。用这些例子只是因为它们简单、抽象，能优雅又贴切地演示递归。若要谈真实世界的实际应用，不如提一个没有平凡 O(1) 解的问题，比如动态规划？文章只用一句简短的话带过：“高级”讨论可能会考虑尾调用行为或缓存结果的可能性。但这恰恰是函数式语言在某些应用数学问题上可能优于命令式语言的原因。我不是说它一定更好，只是说这不是一个简单的论断。换一组例子，这篇文章完全可以写成支持 Lisp 的。我仍认为这是好文章，只是它悄悄塞进去的关于 Lisp 和函数式编程的观点有点站不住脚。
jrajav查看英文原文
I think this article raises a great point overall, but the Fibonacci example is a bit weak and smacks of a strawman. Functional programming tutorials that teach you to write a recursive Fibonacci or factorial calculator are not doing so with the purpose of teaching a useful function, or even a workable one - in fact, more often than not this is called out by showing its performance for moderately large N. They only use those examples because they're simple, abstract problems that can be used to elegantly demonstrate recursion in a relatable way. If we're going to talk about real world, practical applications, then it might be more relevant to bring up a problem for which there isn't a trivial O(1) solution. A dynamic programming problem, perhaps? It's glossed over with a terse dismissal: > “Advanced” discussions might consider engineering considerations such as tail-call behavior, or the possibility of memoizing results. ... But this is exactly why a functional programming language might be better than an imperative for certain applied mathematics problems. Note, I'm not saying that it is better, just that it's not such a simple argument. With a different set of examples, this article could have been written in favor of Lisp just as easily. I still think it's a good article overall, just that the point it tries to sneak in about Lisp and functional programming is a little shaky.
浮点闭式公式在大数上并不优于整数递推，“常数时间”只是偷换了前提。
文章说“若要计算斐波那契数或阶乘，正确解法不是递归函数，而是数学知识”。但如果要大数规模的精确结果，整数递推比把 5 的平方根算到极高精度再取 n 次方要快。作者所谓“正确解法”也许更适合叫“天真的本科线性代数入门学生解法”，或者“不了解计算机数字格式的 18 世纪解析解法”。至于“它们以常数时间运行”：如果人为把数字限制在 double 精度以下，那么整数算法同样可算作“常数时间”，常数就是计算所考虑的最大值所需的开销。或者干脆预计算并缓存整个集合——一共只有 78 个。
jacobolus查看英文原文
> But rarely in these discussions will you find relevant mathematical considerations. If the goal is to compute a Fibonacci number or a factorial, the proper solution is not a recursive function, but rather knowledge of mathematics. If you want precise results for large sizes, then the integer-arithmetic recurrence is faster than computing the square root of 5 to very high precision and raising it to the nth power. The author’s “proper solution” might better be named the “naive undergraduate introductory linear algebra student solution”. Or maybe “18th century analytic solution ignorant of computer number formats”. > They run in constant [...] time If we are going to artificially limit ourselves to numbers smaller than the precision of e.g. double precision floats, then the integer algorithms might just as well be considered “constant time”, where the constant is just whatever it takes to compute the largest value we are considering. Or alternately we can just precompute and cache the entire set of them if we want. There are only 78. Here’s a Javascript implementation const fibcache = [ 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610, 987, 1597, 2584, 4181, 6765, 10946, 17711, 28657, 46368, 75025, 121393, 196418, 317811, 514229, 832040, 1346269, 2178309, 3524578, 5702887, 9227465, 14930352, 24157817, 39088169, 63245986, 102334155, 165580141, 267914296, 433494437, 701408733, 1134903170, 1836311903, 2971215073, 4807526976, 7778742049, 12586269025, 20365011074, 32951280099, 53316291173, 86267571272, 139583862445, 225851433717, 365435296162, 591286729879, 956722026041, 1548008755920, 2504730781961, 4052739537881, 6557470319842, 10610209857723, 17167680177565, 27777890035288, 44945570212853, 72723460248141, 117669030460994, 190392490709135, 308061521170129, 498454011879264, 806515533049393, 1304969544928657, 2111485077978050, 3416454622906707, 5527939700884757, 8944394323791464]; const fibonacci = (n) => fibcache[n];
历次讨论
同类还值得读
开源应用架构
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编辑精选