浅谈 eDSL 在科学计算和数据分析领域的发展趋势

本文来自 “在科学计算和数据分析领域中，今后 Python、R、Julia 各自会有什么样的发展趋势？- 罗秀哲的回答 - 知乎”，经答主授权后由编程语言 Lab 整理并发出。

首先需要提的一点是 Python 的通用性和 Julia 的高性能在下面文章的语境下都是错误的，因为 Python 的 eDSL 大多无法组合，Julia 反而可以有限地组合一些。Julia 也并不是任何程序都性能好，所以这个题目的描述不是非常好。我主要回答的是题目本身。

在科学计算这个领域里提高嵌入式专用语言（eDSL) 相关的功能是这些通用语言在最近几年里的主要方向之一，也是除了具体领域的进展以外对所有人都有用的一个方向。

科学计算领域与 eDSL

首先解释一下什么是专用语言（Domain Specific Language，后简称 DSL），专用语言一般是为某个特定领域设计的，这样可以提供更多的语法糖（syntax sugar）来提高编程效率和可读性，并且由于约束了语义，可以方便优化器进行更有针对性的优化。

随着我们进入后摩尔时代，异构计算（heterogeneous computing）和专用计算（例如各种最近很火的 quantum programming，probabilistic programming 等等）会越来越普遍，这样的结果就是我们将会有越来越多专用语言发明来降低这些本身就不通用的计算模型的编写难度。

而嵌入式专用语言（embedded DSL，后简称 eDSL）是嵌入在某个通用语言的里的专用语言，这样做的好处是用户可以很容易的去组合专用语言写出的功能和通用性的功能，并且由于一定程度上复用了宿主语言（host language）的语法，用户可以几乎不需要学习新语言。此外，由于是嵌入式的，某些专用语言的语义（例如自动微分和一些异构计算硬件）可以缓慢地覆盖宿主语言从而最终实现对整个宿主语言的支持。

改进现有的 eDSL 和相关基础设施是为了有一天可以让大家不用去学习专门的 DSL 语法，而通过编写更加符合直觉的宿主语言，然后通过改变编译的上下文和编译目标来实现对更多硬件，更多计算方式的支持。而不是在宿主语言里硬造出不 Pythonic 或者不 Julian 的语法来，在 Python 里使用大量的 decorator 或者在 Julia 里使用大量的宏是不提倡的，但是很多时候为了支持某些功能是无法避免的，我们当然希望某天一天能够让编译器更加智能。所以，提高 eDSL 的功能不代表需要用户去学习新语言，而是相反，是为了不让用户学习新语言。

此外下文里描述的各种提高不同 eDSL 甚至是不同语言之间的可组合性的努力也是为了在未来可以让编程语言也更加模块化，例如负责概率编程的语言可以和其它语言自由组合，编译器依然能理解他们组装起来以后的程序是什么意思，并提供优化和错误提示。这样反而避免了发明新语言。

下面以 Python 和 Julia 为例简单谈谈我的看法。

Python 的 eDSL 发展

在 Python 里，这两年比较相关的是围绕 Jax [1] 的生态系统和 PyTorch 的 torchscript [2] 以及早年的 numba [3]，当然还有之前知乎上很火热的 taichi [4] 语言，他们实际上都可以算作是 DSL。

Python 由于其本身的性能问题，通过单独编译某个子集一直是常见的提升性能的方案，而这也使得出现了大量的以 Python 作为宿主语言的 DSL。

Python 里的 DSL 要有两种：

伪装成 class 的专用语言

例如 tensorflow 和 theano，他们重载运算符来实现 tracing，然后再编译（也就是我们常说的静态图方案），这样失去了动态性和 Python 本身的反射，随着功能越来愈多会让调试和开发不太方便。并且无法获得宿主的控制流信息。但是好处是由于使用的是 Pyth