Scala 3 不再支持 XML 了吗?
Posted ThoughtWorks洞见
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Scala 3 不再支持 XML 了吗?相关的知识,希望对你有一定的参考价值。
前段时间,我为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公司所有,如需转载请在后台留言联系。
以上是关于Scala 3 不再支持 XML 了吗?的主要内容,如果未能解决你的问题,请参考以下文章
Maven [ERROR] 不再支持源选项 5。请使用 6 或更高版本