Haskell vs. Ada vs. C++ vs. Awk 等多语言对比研究（1994）

导读

这是耶鲁大学 1994 年的一篇经典论文：它让多种语言针对同一个软件原型任务（NSWC 的几何服务组件 geoserver）来实现，比较各方案在代码量、开发效率上的差异，结论是 Haskell 方案远为简洁高效。不过，HN 讨论指出该研究本质上是一次架构设计竞赛（涉及 Rapide 等架构描述语言），Haskell 队伍只处理了被刻意简化的组件功能，甚至因此被取消资格，这也成为评论者质疑其结论的主要理由。

HN 关注点：这是一篇常被用来论证函数式语言生产力的老论文，读者围绕它的比较是否公平、结论在 25 年后是否仍成立展开争论。

关键词　Haskell函数式编程编程语言比较软件架构

HN 评论精选

这几条评论里：质疑 3　亲历 1

质疑Haskell 方案因只关注简化后的组件功能、忽视架构层面而被取消资格，FP 社区有把复杂问题简化后宣称胜利的倾向。

这是很久以前的事了，但我记得为毕业论文研究软件架构时曾看到过这个竞赛。据我回忆，Haskell 的解决方案被取消了资格，而且理由很充分。这个竞赛关注的是系统架构，geoserver 只是一个示例组件——比如 Rapide 就是一种架构描述语言（ADL）。据我所知，Haskell 团队只关注了 geoserver 组件被刻意简化过的功能，而没有关注竞赛真正要考察的架构问题。坦白说，这在函数式编程社区很常见：宣称“复杂的实际问题”其实就是“用 FP 很容易解决的简单问题”，然后解决这个忽略几乎所有真实需求的简化问题，宣布胜利收工。

mpweiher查看英文原文

This is a long time ago, but I remember coming across this competition when studying software architecture for my Diplomarbeit. IIRC, the Haskell solutions were disqualified, and actually for good reasons. The competition was about architecture of the system, with the geoserver an example component. Notice that for example Rapide is an Architecture Description Language (ADL). As far as I can tell, the Haskell team(s) only concerned themselves with the (purposely) simplistic/simplified functionality of the geoserver component, and not the architectural concerns that were the actual point of the competition. Which, quite frankly, is something I see frequently from the FP community: declare that <complicated actual problem> is really <much simpler problem easily solved by FP>, solve the simpler problem that ignores almost all the real requirements, declare victory and go home.

质疑论文太老（早于 monad/HKT/GADT）且漏掉多种当时语言，结论充其量只是高阶函数与 ADT 的胜利。

这很老了，老到早于 monad 作为一种思想出现，更不用说把 monad 作为 IO 问题的解决方案。那时还没有高阶类型（HKT）和 GADT，链表还是各种场景下的主要数据结构，当时的 Haskell 更像 Miranda 而不是今天的 Haskell。而且它漏掉了当时一些常用于原型开发的著名语言：Smalltalk、SML、Eiffel 和 Objective C。如果今天再做这件事，你必然会纳入那些已经发展了 20 年的语言。在有 Scala、OCaml、F#、Idris、Agda、Swift 和 Rust 的世界里，同样的结论还成立吗？说实话，这项研究只是高阶函数和带模式匹配的 ADT 的胜利，别假装它说明了更多。

saosebastiao查看英文原文

It's old. It's so old, it predates Haskell's monads as an idea, let alone a solution to the IO problem. It was before Higher Kinded Types and GADTs. Linked Lists were still the primary data structure for everything. Haskell was more like Miranda than it was like Haskell today. Not only that, but it excluded some of the more prominent languages for prototyping of the time: Smalltalk, SML, Eiffel, and Objective C. And if you were to do it today, you'd invariably have to include languages that have had 20 years to catch up. Would the same result hold in a world with Scala, Ocaml, F#, Idris, Agda, Swift, and Rust? Let's face it, this study was a victory for higher order functions and ADTs with pattern matching. Let's not pretend it was anything more than that.

亲历亲历：Haskell 一周原型让产品负责人满意，类型级不变量减少上线前修复，代码至今仍在生产使用。

这是一篇有趣的论文，我希望 25 年后的今天有人复现它：我相信 Haskell 在这些方面已经成熟了很多。作为一个实验，几个月前我们在工作中用 Haskell 为一个新服务做原型（两个人，都是 Haskell 熟手，限时一周）。结果是：(1) 产品负责人非常满意；(2) 即便代码写得很糟，我们仍然能把业务逻辑编码进类型里，使其始终满足一些重要不变量。结果上生产前需要修的东西出奇地少。最棒的是，由于种种原因，我们没能重写这个原型，所以今天的服务还是同一套代码；但它不是一坨 Python 代码，重构起来非常轻松。补充：有人想看“用 Haskell 快速原型”的博客文章吗？

ff_查看英文原文

This is an interesting paper, and I'd like a replication today, 25y after: I believe Haskell has matured a lot in all of this time. As an experiment, some months ago we prototyped a new service in Haskell at work. We timeboxed a week for it (two people, proficient in Haskell), and the result is that (1) the Product Owners were really pleased with it, and (2) even if it was really bad Haskell code, we _still_ managed to encode business logic in the types so that it would always hold some important invariants. As a result we had to fix a surprisingly small amount of things before putting it in production. The best thing is that as it happens we couldn't properly rewrite the prototype, so today's service is still the same codebase, BUT it's not a Python blob and it was such a breeze to refactor. EDIT: would anyone be interested in a blog post "Rapid Prototyping in Haskell"?

质疑简洁和表达力只是语言价值的两个因素，跨语言比较应看写出同等健壮可维护代码的投入成本。

我记得最早是从 AdaCore 的 Robert Dewar 博士那里听到（大意）：开发阶段（从编译期到 alpha、beta、再到生产）每漏掉一个 bug，其修复成本就上升一个数量级。我绝不是否定简洁语言流畅表达思想的价值，但简洁和表达力只是决定一种语言在特定领域价值的两个因素。这篇论文确实有趣，但每次看到它我都忍不住觉得，在这些特定优点上比较语言有点不太公平，是在拿苹果比橘子。要衡量写出同样健壮、可维护、适用的代码所需的相对时间投入，要困难得多。Dewar 那段话来自这个视频：https://www.youtube.com/watch?v=0yXwnk8Cr0c

ajxs查看英文原文

I believe it was Dr Robert Dewar of AdaCore fame who I first heard remark that ( paraphrased ) every time a bug gets missed at a stage of development ( compile-time to alpha, to beta, to production, etc ) the cost of it's resolution increases by an order of magnitude. I'm certainly by no means dismissing the value of concise languages for expressing ideas fluently, but brevity and expressiveness are only two factors influencing the value of a programming language in a specific domain. It's definitely an interesting paper, every time I see it I can't help but think that it's a little disingenuous to conduct an apples to oranges comparison of languages on these particular merits. It's much more difficult to weigh up the relative investment of time necessary to write code that is equally robust, maintainable and fit for purpose. Here's the video I got the Dr Dewar quote from: https://www.youtube.com/watch?v=0yXwnk8Cr0c

历次讨论

2014Hacker News 讨论帖56 分 · 24 评
2016Hacker News 讨论帖92 分 · 68 评
2019Hacker News 讨论帖68 分 · 55 评

HN 二十年，最值得读的论文。

朋友分享的书单

专题阅读路线

本周最多人读

我的书单

必读 30 篇

论文库

这些论文是怎么挑出来的

全量扫一遍

只留论文本身

写导读、译评论

Haskell vs. Ada vs. C++ vs. Awk 等多语言对比研究（1994）

导读

HN 评论精选

相关资源

历次讨论

同领域还值得读

Google 的软件工程（2017）

Peter Naur：编程作为理论构建 (1985)

SciPy 1.0：Python 科学计算的基础算法

Lisp 的历史（1979）

使用 NumPy 进行数组编程

打赏支持

关注向阳乔木