Scala 3 再也不支持 XML 了吗？

时间 2019-11-05

标签 scala 再也不支持 xml 栏目 Scala 繁體版

原文原文链接

前段时间，我为Scala 3提出了XML字面量语法提案，在社区中正在讨论。这个提案可能预示着 Scala 三、Scala.js和Binding.scala的将来前景。为何这么说？还得先聊聊Scala目前在编程语言界的江湖地位是怎么来的。html

Scala的原做者Martin Odersky同时也是Generic Java（Java 5泛型的前身）的设计者，并且Sun/Oracle的JDK里的javac也源于Martin写的java编译器。考虑到从2004年的Java 5到2014年的Java 8，语言改动很小。能够说这十年间Java语言的基础都是由Generic Java和javac所奠基的。前端

在Genric Java之后，Martin设计了Scala，主要是特点是高度兼容Java字节码，但又结合了函数式编程和面向对象特性，是把编程语言学术界的成果移植到工业界的产物。java

我理解Scala的设计尽可能不在语法上标新立异，而是搞旧瓶装新酒，把现代语言的特性融合到相似Java语法的工业界调调里。好比说函数式编程语言里的ADT，到了Scala里面就用继承实现，对Java程序员来讲很好懂。再如Scala本来设计的赋值符号是“:=”，跟OCaml同样。Martin问了几个码农以后，都说看不懂“:=”，因而Martin就改为和Java同样的“=”了。git

不少复杂的应用不适合用Java这样的工业界流行语言写，由于于这些工业界语言的语言特性相比学术界落后不少，因此写起来很是繁琐、尤为是造DSL能力太差。但若是换用OCaml、Haskell、Idris这样的学术界语言，生态环境又太差，无法用。程序员

Scala解决了这个痛点。由于Scala语言兼容JVM但又比Java简短易读、表达能力强（有研究代表初学者阅读一样功能的Java代码花费时间是Scala代码的1.7倍左右），因此实践中Scala经常被用来开发难度较高的复杂系统的核心部分。好比像是数据挖掘的Spark、消息队列的Kafka，都是用Scala开发核心部分而后支持Java用户使用。github

Scala对工业界的友好性到处可见。好比Scala支持XML字面量功能，要比JSX早了不少年。学院派编程语言绝对不会支持这种“冗余”功能。毕竟一门通用语言要解析XML易如反掌，何须专门设计一个语法呢？可是工业界的实用价值又是另外一回事。编程

除了支持JVM之外，Scala还能够编译成JavaScript（即Scala.js）。Scala在前端开发界的状况和在JVM上相似，兼容JavaScript，但又比JavaScript强大，因此适合复杂系统的核心部分。微信

好比Binding.scala实现了一套数据绑定的monad，而后利用这套monad，结合Scala的XML字面量功能实现了反应式的HTML模板。前端开发只须要把设计好的HTML复制粘贴到Scala文件中，而后把会变的部分替换成变量，整个网站就建好了。这种开发方式一样也被React和JSX所采用，已经成为了2018年前端开发的主流方式了。框架

Binding.scala这样的框架很难在Scala.js之外的技术栈实现出来。在JavaScript里写不出来，是由于JavaScript缺乏了monad这样的函数式编程基础设施，只能像React那样搞虚拟dom，时间复杂度要比Binding.scala的精确数据绑定差得多（参见杨博：如何理解杨博老师对 DOM 操做复杂度的评论？)。在Elm里写不出来，是由于Elm这种学院派调调的语言没有XML字面量功能。顺便说一句，Elm因为和工业界开发方式脱节，成熟度远远不如Scala.js。Elm一共只有337个库，而Scala.js有1315个库。dom

不幸的是，Martin极可能正在背离本身的初衷。

Scala 2的XML字面量是个语法糖，会把XML的语法自动翻译成对scala.xml里的类调用。那么，若是想要把XML翻译成其余库（好比Binding.scala），就须要再写一个宏或者编译器插件，把对scala.xml的调用翻译成对其余库的调用。宏或者编译器插件的编写难度很大，因此能像Binding.scala这样利用起XML字面量的库不多。因此，Martin认为Scala 2的XML字面量功能很难扩展，因而……

Martin提议把XML字面量功能在Scala 3里面删掉。我能够理解学院派语言要保持简洁、阉割掉冗余特性，但我真的没法理解像Scala这样已经被工业界广为接纳的语言要删掉XML，尤为是在JSX如日中天的今日。

因此，针对Martin的提案，我提出了“name-based XML literal”的反提案。我但愿Scala 3可以把XML字面量翻译成能够基于名称的函数调用，用户import了不一样的库，就能够把XML字面量翻译到不一样的库。

Scala 3的特性将会由SIP（Scala Improvement Process）委员会决定。Martin做为Scala的做者固然是委员。Marin对Scala 3的愿景是这样的：

In the future, I want to concentrate on making Scala a better language, with better tooling, as opposed to a more powerful toolbox in which people can write their own language .

意思是但愿让Scala内置不少工具和语言特性，开箱即用，而不是给其余框架用来创造专门语言的工具箱。然而，Martin的想法和构成Scala生态环境的不少Scala框架背道而驰，由于这些框架刚好是看重Scala定制DSL的能力才选用Scala的。前面说的Binding.scala是把Scala当成HTML模板DSL来用，Spark则是把Scala当成MapReduce的DSL来用，还有Chisel搞了设计集成电路的DSL。

因此，在9月SIP会议讨论XML的前景时，Martin表态想移除XML，“believes Scala is instead a more lightweight language than its competitors”。相比之下，其余SIP委员，好比Scala.js的做者Sébastien Doeraene，则对移除XML形成的影响表示担心。

目前XML在Scala 3中的命运仍然悬而未决。这个特性的去留可能暗示了Scala 3到底能成为一门适合工业界实际应用的语言，仍是一门精简优雅的学院派语言。