Scala 3的XML字面量功能引发了社区的讨论。Scala的创始人Martin Odersky提议删除XML支持，认为其难以扩展。然而，这一决定受到质疑，因为XML在构建DSL和库如Binding.scala中的重要性。反提案建议保留XML，通过名称基础的转换实现更多灵活性。Scala 3的未来方向——是成为更轻量级的语言还是保持强大的DSL构建能力，仍待SIP委员会的决定。
前段时间，我为Scala 3提出了XML字面量语法提案，在社区中正在讨论。这个提案可能预示着 Scala 3、Scala.js和Binding.scala的未来前景。为什么这么说？还得先聊聊Scala目前在编程语言界的江湖地位是怎么来的。
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字节码，但又结合了函数式编程和面向对象特性，是把编程语言学术界的成果移植到工业界的产物。
我理解Scala的设计尽量不在语法上标新立异，而是搞旧瓶装新酒，把现代语言的特性融合到类似Java语法的工业界调调里。比如说函数式编程语言里的ADT，到了Scala里面就用继承实现，对Java程序员来说很好懂。再如Scala原本设计的赋值符号是“:=”，跟OCaml一样。Martin问了几个码农之后，都说看不懂“:=”，于是Martin就改成和Java一样的“=”了。
很多复杂的应用不适合用Java这样的工业界流行语言写，因为于这些工业界语言的语言特性相比学术界落后很多，所以写起来非常繁琐、尤其是造DSL能力太差。但如果换用OCaml、Haskell、Idris这样的学术界语言，生态环境又太差，没法用。
Scala解决了这个痛点。因为Scala语言兼容JVM但又比Java简短易读、表达能力强（有研究表明初学者阅读同样功能的Java代码花费时间是Scala代码的1.7倍左右），所以实践中Scala常常被用来开发难度较高的复杂系统的核心部分。比如像是数据挖掘的Spark、消息队列的Kafka，都是用Scala开发核心部分然后支持Java用户使用。
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个库。
不幸的是，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到底能成为一门适合工业界实际应用的语言，还是一门精简优雅的学院派语言。
相关链接：
Binding.scala
Scala.js
SIP委员会9月会议纪要
Scala XML讨论摘要
name-based XML literal
移除XML的提案
文/ThoughtWorks杨博
更多精彩洞见，请关注微信公众号：ThoughtWorks洞见
731
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
![[外链图片转存失败(img-3E7i68SE-1562723081832)(https://insights.thoughtworks.cn/wp-content/uploads/2019/07/scala-1.png)]](https://insights.thoughtworks.cn/wp-content/uploads/2019/07/scala-1.png){kind=link}