Jane Street 为什么使用 OCaml

Jane Street 在种类繁多的软件中使用 OCaml。从外部看，这个选择可能有些奇怪，因此我想解释这门语言给我们带来了什么，为什么我们认为它适合一家交易公司，以及为此付出了什么代价。

一种有用但并不完美的分类方式，是沿着两个维度划分编程语言：命令式与函数式，以及动态类型与静态类型。这些类别没有精确的边界；语言之间会互相借鉴，人们也可以用不同风格使用同一种语言。

在命令式一侧，Python 和 Ruby 这样的动态语言通常容易编写，也方便快速试验。Java 和 C 等静态类型语言往往要求更明确的结构，但运行速度可以快得多。这些是总体趋势，并非定律。

静态语言通常可以提前作出一些决定，而动态语言必须等到运行时才处理。即使是加法，也可能因参与运算的值而有不同含义；决定执行哪种操作的机制本身需要成本。这有助于解释为什么看起来相似的代码速度可能相差很大。

一位听众指出，静态类型代码也可以动态检查类型。我同意：这些类别的边界很模糊。例如，Java 有反射功能，这种运行时灵活性也可能带来性能成本。

类型还有助于保证正确性。历史上，Fortran 的静态类型帮助数值计算实现高速运行，而 Lisp 则处在语言地图中截然不同的位置。如今，类型还可以表达程序的性质，帮助我们在程序运行前发现错误。

函数式语言通常把函数当作轻量的值：你可以把函数传给其他函数、将其作为返回值，也可以存入数据结构。它们还支持一种避免修改状态的编程风格，也就是在计算过程中不反复改变值。

如果你习惯于在循环中更新变量来完成计算，这听起来可能很奇怪。但我们可以在不改变初始数据的情况下表达计算。列表求和就是一个简单的例子。

Python 版本先把总和设为零，遍历列表，并不断增加总和。OCaml 版本用递归函数检查列表：空列表的和是零，非空列表的和则是表头加上其余部分的和。两者使用不同的编程习惯表达了同一项计算。

一位听众询问递归和栈空间的问题。有些递归形式可以优化成循环，而这个简单版本也不是唯一的实现方式。这个例子意在展示如何不用可变的累加器来表达计算，并不是说所有递归写法的性能都一样。

为什么要避免修改状态？当多段代码共享一个可以改变的值时，一部分代码可能以局部难以察觉的方式影响另一部分。不可变数据减少了这些隐形的通信渠道，让组件更容易理解和组合。

并发情况下，这个好处尤其明显：共享的可变状态需要协调，以免不同线程相互干扰。纯函数更容易推理，因为结果取决于输入，而不是不可见的状态变化历史。

这并不意味着有用的程序绝不能产生副作用。程序必须与外界交互、读取数据并产出结果。关键是有意识地管理状态修改和副作用，而不是让它们到处蔓延。

一位听众问，面向对象的封装是否也能控制可变状态。它确实有帮助，但抽象仍然必须考虑状态变化的各种方式。函数式技术提供了另一种方法，减少我们需要理解的交互。

静态类型的函数式语言包括 OCaml、Standard ML、Haskell、Scala 和 F#。这些语言将函数式编程与能在执行前发现错误的类型系统结合起来。OCaml 的类型推断通常可以自行算出类型，无须程序员为每个表达式添加标注。

对于列表求和函数，编译器可以推断出输入是整数列表，结果是整数。代码可以保持简洁，同时获得静态类型带来的性能和检查能力。类型推断也有取舍：错误信息有时可能难以理解。

在这场演讲的大约十年前，Jane Street 开始转向 OCaml。交易软件需要正确运行：错误可能造成极其高昂的损失，而市场环境中既有异常事件，也有追逐自身利益的其他参与者。

测试很重要，但它无法覆盖所有可能的情况。金融结果可能呈现肥尾分布，罕见故障的后果可能远比普通故障严重。类型系统提供了另一种方法，在上线前排除某些类别的错误，是对测试的补充，而非替代。

考虑一段比较两个字典的 Python 代码。如果它遍历第一个字典的键，并假定每个键也存在于第二个字典，缺失的键就可能引发运行时异常。程序逻辑悄悄依赖了一个从未验证的假设。

在 OCaml 中，映射查找可以返回一个可选值：要么值存在，要么不存在。模式匹配促使程序员面对这两种可能性。语言不会神奇地决定正确的业务行为，但它会在需要作出设计决定的地方明确提示缺失情况。

这就是为什么我把类型系统视为设计工具，而不只是捕捉笔误的方法。它鼓励我们描述业务领域中可能发生的情况，让我们在实现行为时更不容易遗漏其中一种。

另一个例子是一门小型布尔表达式语言。我们可以表示真与假、与、或、非，以及一个含义由外部提供的基本情况。表达式的结构与它所检验的具体事实是分开的。

求值器递归遍历这个结构，组合子表达式的结果，并调用提供的函数来解释基本情况。对邮件过滤器来说，基本情况可能是判断发件人或主题是否符合某个条件；另一个应用则可以使用相同的布尔机制，配上不同的谓词。

这个例子展示了一等函数、代数数据类型和模式匹配的结合。类型可以精确描述表达式可能具有的形式，匹配则能把各种情况展现出来。我把它与 Java 作了比较，同时承认这种具体比较对 Java 并不完全公平。

OCaml 的适用范围很广。它足够简洁，可以完成原本可能交给脚本语言的任务；它又能编译成高效代码，并提供表达力丰富的静态类型。在 Jane Street，我们用它编写脚本、处理配置相关工作，也用它构建交易系统。

在多种工作中使用同一种语言，对组织也有好处。代码库和想法可以共享，人员在项目之间流动也更容易。演讲时，公司约有 400 名员工，其中约 70 人是全职开发者。

一个合理的担忧是，相对陌生的语言是否太难学。我不认为使用 OCaml 需要特别聪明的程序员，尽管我也意识到自己的经验可能存在选择偏差。

我们的交易员培训包含大约一个月的编程教学。大约一半的参与者最终能够进行实际编程。我们还看到，不同基础的实习生——包括学过 OCaml 的哈佛学生和没学过的 MIT 学生——都能在几周后完成简单项目的部分工作。

另一个担忧是招聘。早期我们在 OCaml 邮件列表上发布消息，收到了约 15 份回复，进一步联系了其中约 12 人，邀请 5 人到现场，最终录用了 3 人。这在公司规模较小时很有用；但更持久的效果是，这种选择吸引了对语言感兴趣、否则可能不会考虑金融公司的求职者。

Stephen Weeks 就是一个例子：他对技术工作的兴趣促使他加入 Jane Street。因此，语言选择既可能限制招聘，也可能成为优势，尽管它不会吸引所有人。

最大的缺点是生态系统较小。与最流行的语言相比，现成的代码库和工具较少，我们不得不投入资源改善周边基础设施。OPAM、Merlin、OCP-indent 和文档工具等项目有所帮助，但成本确实存在。

对我们而言，收益足以证明这些投入值得。我并不是说 OCaml 对所有人都是正确选择；我是在解释为什么富有表达力的类型、函数式编程、速度以及统一语言的组合，在我们的环境中运作得很好。

被问到这些思想为什么没有传播得更快时，我提到了网络效应和惯性。人们接受的是现有工具的培训，组织已有代码，而编程语言也会引发强烈的个人认同。很难为一种语言普及或未能普及确定单一原因。

衡量一种语言带来的生产力优势也很难。最重要的差异可能出现在多年维护过程和大型代码库中，而不是短时间比较某人编写小程序的速度。这使得有把握地提出具体数字很难得到充分证实。

听众问及其他地方的采用情况。函数式语言及相关思想已经在其他公司得到应用，包括 Facebook 在 Hack 和 Flow 上的工作，以及 Twitter 使用 Scala。这些例子反映的是演讲时的情况，并不意味着每个组织都应该与 Jane Street 作出相同选择。

语言选择受到技术需求、现有社区、可用工具，以及组织能够吸引和培养的人才影响。我们的经验是：当一种不寻常的选择的优势与工作相匹配，且组织愿意投入生态建设时，它可以是务实的选择。