前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >Scala 3 不再支持 XML 了吗?

Scala 3 不再支持 XML 了吗?

作者头像
ThoughtWorks
发布2019-07-09 16:45:55
1.1K0
发布2019-07-09 16:45:55
举报
文章被收录于专栏:ThoughtWorks

前段时间,我为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的提案

- 相关阅读 -

React 单元测试策略及落地

开发者如何快速熟悉一个新敏捷项目

点击【阅读原文】可至洞见网站查看原文&绿色字体部分的相关链接。

本文版权属ThoughtWorks公司所有,如需转载请在后台留言联系。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2019-07-04,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 ThoughtWorks洞见 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 点击【阅读原文】可至洞见网站查看原文&绿色字体部分的相关链接。
相关产品与服务
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档