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

本网站用的阿里云ECS,推荐大家用。自己搞个学习研究也不错

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

更多文章请点击http://go2live.cn

未经允许不得转载:演道网 » 回顾:在生产环境中使用Haskell

赞 (0)
分享到:更多 ()

评论 0

评论前必须登录!

登陆 注册