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

阅读数:2537 2011 年 12 月 8 日 00:27

近日,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 发表评论