BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

观点:Scala会成为新的EJB 2吗?

| 作者 Alex Blewitt 关注 4 他的粉丝 ,译者 张龙 关注 12 他的粉丝 发布于 2011年12月9日. 估计阅读时间: 6 分钟 | GMTC大前端的下一站,PWA、Web框架、Node等最新最热的大前端话题邀你一起共同探讨。

近日,Joda Time库的开发者与JSR 310 Java语言日期时间改进的规范领导Stephen Colebourne就Scala语言的适用性发表了一篇令人深思的文章。他比较了Scala与EJB 2,并认为EJB 2是Java EE规范的低谷。

...大量的样板代码、XML和复杂性已经渗透到了Java产业中。规范已被广泛采纳,但与这种采纳相伴的却是批评。开发者发现虽然EJB 2试图通过抽象的更高层的API来降低构建企业应用的复杂性,但事实上,它却增加了更多的复杂性,并且没有获得预期的结果。

虽然他偏爱Fantom语言——但也对其他语言如Kotlin、Groovy和Ceylon充满了好感——他认为Scala并不适合于未来的发展。

他感到不爽的一个地方就是Scala并未提供合适的模块化系统。他说Java一开始也没有提供模块化系统(目前依旧没有,但至少这是现在人们普遍存在的一个需求),只能通过其他手段如Maven、Ivy和OSGi等达成。然而,那些忽视模块化系统的人还是会给需要的人带来麻烦;在处理大型系统时,模块化将成为重要的维护工具。

Stephen还表示假如Java有模块化系统,那么就可以发布不支持CORBA的JVM了,CORBA是个遗留技术,在Java领域中,除了RMI外现在已经很少使用了(对于服务器间的通讯来说,CORBA已经逐步被SOAP和REST所取代)。

事实上,两年前就有人提出了关于模块化的提案,但很快就被束之高阁。对于模块与版本存在很严重的阻力(每个模块系统都需要依赖他们来运作)。在那时,Scala尚未进入到企业;两年过去了,Scala的境况依然如故。

Stephen还指出类型系统过于复杂了,在这一点上,他认同Steve Yegge的观点:

语言规范,天哪,我简直无话可说了。我必须得在博客上写点什么才行。规范中大约90%的内容都是关于类型系统。这将是你有生之年所能见到的最大的类型系统,其复杂程度并不是一个数量级,甚至能达到5个量级。除了类型就是类型,然后还是类型;太复杂了。

他们称其为complexity complexity,这意味着它并不仅仅是complexity的问题;也不是complexity-complexity的问题:而是参数化的complexity-complexity,我要说的是这种东西就是在类型上堆积类型,然后再不断地堆积类型,太糙了吧。

Stephen还重点强调了类型签名——一开始用于表示方法能够正确编译——现在变得越来越没有意义了,甚至在支持Unicode方法前就这样了。他给出了如下的方法签名,来自于Scala核心库,他想知道这个方法到底是干啥的:

def ++ [B >: A, That] (that: TraversableOnce[B])(implicit bf: CanBuildFrom[List[A], B, That]) : That

事实上,Stephen认为使用静态类型会给静态类型蒙羞:

我想说的是,这个庞大的类型系统目的在于防止编译错误,并且对代码进行预检查。但要是将这种逻辑放到动态类型系统的语言中就不行了。对于我来说,Scala的类型系统已经背离了语言特性的本质。

本质上,Scala的类型系统给静态类型蒙羞了。

上面这些并不是什么新观点。Log4J与SLF4J项目的创建者Ceki Gülcü就在问Scala是否值得信任,因为这门语言已经演化了很多,多次违背了向后兼容性(未来也不见得会解决这个问题):

然而,Scala语言有一点让我颇为不爽。每次新版本发布时,Scala都破坏了二进制兼容性。尽管之前做过许诺,但2.7版依然破坏了兼容性,2.8版又是这样,2.9也不例外。我清楚这一点,当Scala库的特性以一种不兼容的方式发生变化时,Scala语言的设计者也只能置兼容性于不顾了。

将Ceki的观点展开,在Java出现前,要想在不同操作系统和版本间实现可移植性,从源代码进行编译是不二之选。直到标准C ABI出现后,我们才可以在相同操作系统的不同版本间使用相同的二进制文件,最终导致了诸如Debian、RedHat和Ubuntu等二进制发布包的出现。由于缺少这些ABI,很多公司都无法在早期的Linux内核1.x和操作系统上安装其商业产品的二进制版本(他们当然不想共享源代码了)。

Ceki进一步说到“相互竞争的语言间的差距最终将会缩小,Scala也将不会像现在这么酷了”。在一开始,Scala有机会激发众多Java程序员的想象力。它诱使那些想要学习函数式编程的程序员们学习它,同时Scala又提供了更为简洁的代码。但由于一次又一次地将语言稳定性这一要义抛之脑后,同时又沿用几年前Java所用的那些手段(但却忽视了Java在各个版本间的兼容性),这一切都使得Scala游走于主流企业项目的边缘地带。没错,一开始是有些团队采用Scala并获得成功,但到目前为止,我还没听说哪个团队能够在一两年后还能继续维护好Scala代码基。

现在,有不少基于JVM的语言都值得我们去探索,从Fantom到Xtend,这些语言正在不断蚕食Scala的地位。甚至连Java都要在下一版本中提供模块化和lambda了;虽然被推迟了一年多,但将函数式编程带到Java中肯定要比Scala达到稳定快得多。在Scala步入正轨前Java将会迎头赶上。Scala,你太晚了。

查看英文原文:Opinion: Is Scala the new EJB 2?

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

矮油 by Jeffrey Zhao

终于发布袅!

简单并不简单 by stepone wang

scala宣称的简单并不简单,类型系统的确是太复杂了,通过约定来控制还是有风险的,不过写了scala后,的确感觉java有点又臭又长,太多的无功效代码,二进制兼容的问题的确让人窝火!这么长时间了难道还没确定特性边界吗?好消息是Idea插件对scala的支持终于比较成熟了,至少可用了。我比较期望的特性是反射完善起来,有一个官方的script engine出来。

Scala的复杂和简单 by zaixiang wang

Scala复杂性不容置疑,而言其复杂性也确实在静态类型一块。此外,要做到scala的强大反射支持,现在看起来似乎是一个不太现实的目标。

然而,scala似乎又在简洁性上非常完美,非常一致的语法,非常简洁的类型定义、语法甜品、类型匹配等,在最坏的情况下,你可以把scala当作一个更简洁的Java。

我想,如果把scala的复杂性控制在framework、library之下,而在上层提供简洁的应用模式,或许是一种不错的组合。这就需要应用团队做一定的限制:尽量不要在自己的应用层面使用带来复杂的scala特性,我个人认为包括:implicit、复杂的泛型、运算符重载(个人认为运算符重载不应超出Java自身的运算符范畴)。

再谈scala的复杂性 by zaixiang wang

<quote>def ++ [B >: A, That] (that: TraversableOnce)(implicit bf: CanBuildFrom[List[A], B, That]) : That<quote>
我看到很多的帖子都在拿这行代码来说明scala的复杂性,确实,我也是花了很长时间才明白这行代码的。不过,了解以后,还真是觉得,这正是scala的强大之处。而且学习以后也没有那么难的理解这行代码了。

这就是说,scala的复杂,其实是相对Java而言的,但在scala的世界中,他的类型体系确实是一个内部完善、自部统一的体系,如果多花一些时间来学习,也是可以理解他的简单性的。(不了解他的话,自然复杂了,就像汇编的人也会感觉到Java在很多感念上的复杂一样)</quote></quote>

Re: Scala的复杂和简单 by Zheng Ken

我觉得大多数用scala的都没太搞明白他们需要什么。
groovy+grails最终会被证明是王道---仅仅因为简单。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

5 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT