stephen colebourne的 scala是EJB2观点引起很大反响,专门讨论:Scala EJB 2 feedback, 另外一篇:Scala feels like EJB 2, and other thoughts
stephen colebourne首先比较了Fantom和scala:他认为Fantom把复杂性花在了程序员关心的地方,而Scala把复杂性花在了他不关心的地方。
Scala的模块性存在问题,当然Java也缺乏模块性,虽然有 Maven, Ivy 和 OSGi,这些技术总是有优缺点,没有平台自己整合更自然 。stephen认为就是Scala和Maven/Ivy整合也并不好,它错过了现实生产领域的大好机会。向后兼容已经成为Scala一个顽固问题,而模块化可以管理版本兼容等问题。模块化是允许应用发现在classpath/modulepath中所有Class,这样容易实现这些路径下的某个接口或Annotation,虽然Java和Scala能做到这些,但是通过scannotation这样复杂而且慢的扫描工具。
在并发方面,Scala其实是讲了一个很美故事,实际情况并不和描述的符合(banq注:是不是LMAX团队在测试Actor时发现并不能满足要求,自己创建了Disruptor框架)。Scala可能会将一个可变的状态对象传给Actor:
object Foo {
var bar = "Hello" // this is shared mutable state
val baz = new Mutable() // so is this
}
而跟踪可变状态是困难,语言设计时,应该仅仅允许不可变对象的引用被传送到另外一个线程或Actor,这样就从根本上消灭了共享可变状态的并发隐患。Fantom则将这个特性加入,这种情况下不会被编译。当然这可能是Scala特点,给予程序员信任和权力,尽量避免打扰他们。而stephen认为这正是Scala无法实现大规模编程的根源。
在类型方面,向一个整数型List集合加入String,结果编译错误,而不是一个any类型的List集合,stephen认为Scala的类型自动化功能很多并不是他想要的,不对胃口。
Scala在语法方面相当灵活,到处有可选的技巧,这就需要程序员开一个很大的邮件列表来讨论如何在合适地方采取合适的可选项,也就是最佳实践方式太多也不是一件好事,甚至IDE和编译器都不知道代码是什么意思了。
在社区方面:Scala有很响亮的社区,特别是在Twitter上,一些开发者已经创建基于Scala的库,以及Web框架和数据库访问库,这些好像让Scala似乎成为明日之星,暗示其他开发者应该投入更多时间来学习它。
很不幸,在社区方面也有一些负面现象: Scala似乎只吸引那些崇尚类型理论,以及hard-core函数编程 functional programming以及数学思维编程者(mathematical end of programming). 经常他们也遇到在A B C D中选择哪个更好地激烈辩论,Scala往往提供通往一个目的的多种实现路径,而Java则好些,避免造成过多的辩论。这也就是为什么有人总是搞不明白其他人为什么总是搞不明白Scala/Type/FP 这些对于他们来说很简单的概念,甚至指责这些人为二等公民。
而stephen认为大多数程序是聪明的,问题是类型系统的复杂性并不是关注重点,他们关注的是他们正在运行的系统架构。
stephen针对自己被批评为散布恐惧 不确定和怀疑(简称FUD)做出辩解:一些人称赞stephen能够勇敢站出来面对邪教Scala(Scala cult)。
评价一个语言是看他抛弃以前语言有多少,然后自己增加了多少,正如Java抛弃C的一些东西加了自己的东西,而Scala则并没有抛弃太多东西,反而加入了更多的东西。
[该贴被banq于2011-11-29 13:46修改过]