回顾:在生产环境中使用 Haskell

阅读数:1855 2016 年 8 月 29 日

话题:函数式编程语言 & 开发文化 & 方法

Better 联合创始人 Carl Baatz 发表了一篇博文,总结了他们四年来在生产环境中使用 Haskell 的情况。他写道,在构建服务器端软件时,Haskell 可能“最像是秘密武器了”。Baatz 从四个不同的角度进行了回顾:你们能完成工作吗?在实践中,它会导致延期吗?你们能招聘到开发人员吗?应该有更多的公司使用它吗?

他们构建了一个“每周处理 50 万个操作”的系统。该系统“已经稳定地运行了一年多,没有宕机或维护。”下面是 Baatz 从中学习到的一些经验:

  • 只需要相当有限的知识就可以使用 Haskell 完成构建,但如果希望有非常高的生产力,就需要大量地学习;
  • cabal-install对于初学者而言不太友好,但 Stack 让工作更简单;
  • 生态系统“还不错,但不是很好”;
  • Laziness 使得开发人员需要仔细考虑空间复杂度;
  • Haskell 的类型系统使得代码很容易重构和扩展;
  • Haskell 的类型系统降低了通过单元测试捕获不一致的需要,虽然 Haskell 使用QuickCheck对单元测试提供了很好地支持;
  • 招聘程序员比预期容易,许多程序员为使用 Haskell 的前景所吸引。

为了进一步了解他的经验,InfoQ 采访了 Carl Baatz。

在您的博文中,其中有一个观点是,Haskell 让你可以构建一个几乎没有 Bug 的系统。对此,您能更详细地说明下吗?

我不是说系统没有 Bug,但我们目前还没有发现任何 Bug(已经稳定运行了一年多)。我们的工程团队值得赞扬。对于这门语言以及我们如何使用它,我也许可以提供一些有用的信息。

对于初学者而言,Haskell 的类型系统确实可以确保更高程度的一致性,比许多主流语言都高。根据我的经验,在动态类型语言中,Bug 通常是重构导致的“低级”错误:我修改了一个对象的字段属性,但没有将用到它的地方全部更新。在 Haskell 中,编译器会告诉你遗漏了什么,因为你所做的修改改变了对象的类型,使得修改后的对象和以前的使用前提出现了不一致。

该语言还鼓励你使用一种具有“强静态保障(strong static guarantees)”的编程风格。例如,你可以将配置信息一个字符串一个字符串地保存在词典中,然后在使用配置信息的地方处理丢失或无效的条目。不过,具体指定配置类型通常很容易;例如,你可以规定,它必须有一个整数类型的端口。然后,你就可以在任何地方使用它——你知道端口查找不会失败。当然,从磁盘读取配置信息可能会失败,你可以通过退出程序或提供一个默认值来处理那种情况。

另外一个有用的东西是不可变数据和 Purity(限制副作用)。不可变数据是指,我们可以安全地共享值,并把值传递给函数,而不必担心它们在我们不知情的情况下发生变化。限制副作用是指,如果函数执行不可预测的操作,如读取文件和获取随机数(即输入 / 输出),就必须显式标记,并且只能在其他这样的函数中使用。对于这样的输入 / 输出函数,要尽可能地保持简单,将大部分逻辑移到单独的函数中。这样做使得程序推断简单了许多,尤其是当复杂度增加时。

公平地说,我们还应该指出,Haskell 有个地方可能比传统的语言更容易引入 Bug:空间使用。因为 Haskell 是懒惰的,很难推断空间复杂度,那会导致“泄漏”(不是真正的泄漏,而是使用很大的内存)。这不是无法解决的问题,但需要注意跟踪这类情况。

还有更多内容可以介绍,但我要说,前面那些内容就是要点。当然,有许多东西是语言和编译器无法检测的:你的授权模型可靠吗?你的计算正确吗?你的网站显示了恰当的标签吗?

你们没有做 TDD,也没有追求单元测试的完全覆盖。那你们采用什么方法测试变更?你们定义了什么类型的测试?其中哪一种最有价值?

我们使用了一种实用的测试方法:只有当编写测试的成本低于预期的 Bug 修复成本才编写测试。因而,我们针对可能损坏数据库的代码编写了测试,我们在重大部署之前测试性能 / 负载处理。在开发过程中,我们当然也会有 Bug,但我不记得有哪一个成本很高,通常很快就可以修复。特别地,我们可以放心地重构代码,这很关键,不需要测试(这还是得益于 Haskell 的类型系统)。

另一方面,我认为,可以将 Haskell 的类型系统视为一个由编译器运行的测试套件,这还是很有用的。从那个角度来看,Haskell 及其他具有强表达性静态类型系统的语言实际上都有许多“测试”(它们每次编译时都运行),只是,它们不是我们通常所认为的传统测试。

在上市时间方面,Haskell 提供了什么优势,如果有的话?

Haskell 并没有一个像 Ruby 和 JavaScript 那样的库和工具的生态系统,也就无法像 Ruby 和 JavaScript 那样快速地创建一个 Web 项目。因此,它在原型阶段要慢一些。我不认为那是语言的内在缺陷。不过,其生态系统确实是缺少一些我们希望能有的东西。另一方面,在快速编写和修改需要在生产环境中运行的代码时,Haskell 很强大,因为我们可以少写测试,并放心地重构。如果更笼统一点讲,有人可能会认为,Haskell 的初始成本高,而总拥有成本低。我认为,初始成本也可以降低,但我们还没有做到。

如何提供一种更好的 Haskell 开发体验?

第一样东西可能是库。Haskell 的生态系统还不错,但举例来说,不如 Java、Ruby、Python、JavaScript 的生态系统丰富。不过,它也在稳步改善,去年已经取得了重大的进展。然而,质量更高的库和工具肯定会受到欢迎。我认为,随着社区的发展以及更多公司开始在生产环境中使用 Haskell,其生态系统会不断改善(尽管不可否认,有个鸡蛋相生的问题)。

另一样让人们打退堂鼓的东西是文档,其中经常缺少一些人们希望有的东西。不同于类型,许多库即使有文档也很少。此外,我认为,有更多高质量的一般性学习资料也是有好处的。虽然现在已经有一些资料,情况也在改善,但还有很长的路要走。

最后一样东西,我可能得说更好的 IDE。虽然大部分 Haskell 开发人员都对 vim/emacs 感到满意。但我认为,一个现代化的、能够识别 Haskell 类型系统的 IDE 可以降低门槛,对提高生产力也有很大的好处。有些 Haskell IDE 服务器(它会连接到各种文本编辑器和 IDE)相关的工作已在进行当中,那是个积极的信号。不过,关于这一点,有人比我更了解。我从他们那里了解到,一个真正优秀的 IDE 服务器需要对编译器本身做重大修改。因此,可能还需要一段时间。

还有一样东西,有些人可能会把它列为潜在的改进点,就是语言稳定性。即使语言和基础库一次又一次地引入了破坏性变化,并招致了运维负担,但好处是,该语言保持着相对的简洁,改善了日常的工作体验。在我个人看来,那是一种比较好的折衷。不过,有些人可能会不赞同。

Better成立于 2012 年,旨在构建一个基于云的学习平台,并可以集成到企业现有的学习管理系统。2016 年初,该公司被GRC Solutions收购。

查看英文原文:Retrospective: Haskell in Production