编程与软件工程haskell.cs.yale.edu
Haskell vs. Ada vs. C++ vs. Awk（1994）[PDF]
Haskell vs. Ada vs. C++ vs. Awk vs (1994) [pdf]
2014 — 2019，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是耶鲁大学 1994 年的一篇经典论文，比较 Haskell、Ada、C++、Awk 等语言在实现同一个地理服务（geoserver）组件原型时的开发效率，常被引用来说明函数式语言代码更短、原型更快。评论也提醒：实验年代久远、范围有限，且 Haskell 方案曾被质疑只解决了简化后的功能问题，而非竞赛真正关注的架构问题。
为什么经久不衰：它提供了一个常被引用的跨语言原型生产力对比案例，也因方法争议成为讨论函数式语言优势与局限的经典材料。
HN 评论精选
他认为 Haskell 方案被取消资格有道理，因为它只做了简化功能，没解决竞赛真正关心的架构问题。
这是很久以前的事了，但我记得在写毕业论文、研究软件架构时读到过这个竞赛。据我回忆，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.
这项研究年代太早、语言选择有限，最多证明了高阶函数和模式匹配 ADT 的价值。
这很老。老到早于 monads 作为一种想法出现，更不用说作为 IO 问题的解决方案。它早于 Higher Kinded Types 和 GADTs。链表仍是所有东西的主要数据结构。那时的 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）即使代码是很糟的 Haskell，我们仍然设法把业务逻辑编码进类型，使其始终满足一些重要不变量。结果上线前要修的东西少得惊人。最好的是，后来我们没能好好重写这个原型，所以今天的服务仍是同一套代码，但它不是一坨 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，解决它的成本就会增加一个数量级。我绝不是否定简洁语言流畅表达想法的价值，但简洁和表达力只是影响一种语言在特定领域价值的两个因素。这确实是一篇有趣的论文，但每次看到它，我都忍不住觉得在这些特定优点上做苹果对橘子的语言比较有点不真诚。要权衡写出同样健壮、可维护、适合用途的代码所需的相对时间投入，要困难得多。引文出自视频：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
历次讨论
同类还值得读
开源应用架构
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编辑精选