Scala象EJB2吗?

两篇文章两种观点,Scala - 正在流行用户不断增加,而另外一篇:Is Scala Like EJB2?

看到这篇Scala好像是EJB2时,我有些同感,因为Scala的Actor初次给我的感觉非常象EJB的有态Bean。

该文作者认为EJB2带来了不必要的复杂性,而Scala可能也犯了和EJB2一样的问题,导致复杂性,比如作者写了一段复杂Scala代码:

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

为了使用这个方法,需要理解其中很多细节。

2011年11月26日 10:21 "@banq"的内容
两篇文章两种观点,Scala - 正在流行用户不断增加,而另外一篇:Is Scala Like EJB2? ...

这句话有失了。scala是语言而已,Actor模型是从Erlang引进过来的。其区别是更关注逻辑而已。

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修改过]

在语法方面,你可能看到很多资料说Scala比Java使用更少的代码,它似乎是多么地简单,这其实是一种聪明的技巧罢了,当你开始每一个看似简单代码混合在一起时,复杂性就来了,在一个大的团队中,超过一定时间,代码阅读量远超过其编写量(程序员都变成读代码者了?),这就是你体会Java会有一些限制的原因。


在质量方面,当评估一种语言,重要的是得到其实施质量。确定维持目前的语言和在未来扩大它则将会容易,这种方式是有用的。这样stephen对Scala的主要贡献者Paul Phillips进行了关于测试方面的对话,一个令人难以置信的复杂的语言竟然极少测试?

如果你想采纳Scala作为团队语言,推荐你看一下这段视频:http://scalatypes.com/webpage/interview-with-paul-phillips,它将帮助你了解Scala真正面对的问题和困难。

stephen总结道:我并不喜欢Scala,而且这种不喜欢与日俱增,我并不想把我的未来职业生涯花在它上面

如果Scala作为一个非主流语言,如同Haskell or Erlang,我并不感冒,但是它现在好像被包装成一种主流开发语言, 它真的丑陋得像EJB2。


这一周是Scala黑色星期五,噩耗不断传来,号称企业Twitter的Yammer在下面一封信中声称以后重点从Scala转向Java:http://codahale.com/downloads/email-to-donald.txt

Right now at Yammer we're moving our basic infrastructure stack over to Java, and keeping Scala support around in the form of facades and legacy libraries.

We'll still have Scala in production, probably in perpetuity, but
going forward our main development target will be Java.

我就一直没搞清scala到底给java程序员带来了什么。或者说解决了哪些用java很难解决的问题。。。
语法太灵活了不是好事,如果公司要采用scala,肯定也得弄个编码规范出来,肯定不能想怎么写
就怎么写。java用akka库,也能拥有Actor。

2011年12月01日 10:02 "@banq"的内容
称企业Twitter的Yammer在下面一封信中声称以后重点从Scala转向Java .. ...

这事搞得有点大,刚才Yammer官方网站正式登出:SCALA AT YAMMER,重申转向Java只是个人的信件,不是官方宣称,YAMMER说过去两年使用Scala建立了很多后台服务,他们只是在一些个别组件上觉得Java更合适,语言只是他们的工具,现在Scala还只是当初Java 1.3阶段。

另外一篇:语言批评Language criticism,这是位Clojure粉丝认为Coda并没有说Scala不好,而是说:Scala并不是在这个时候平衡各种因素后的最佳选择。他顺便也推荐了一把Clojure,他们也遇到了年轻语言同样的问题,但是他们没有回头选择Java,而是不断开拓。

语言走在十字路口,未来语言方向确实事关重大,我好象又看到了当初Spring和EJB2争论景象重现,不过这次虽然指出Scala类似EJB2,却没有一个新的类似当初Spring的替代品。

[该贴被banq于2011-12-01 14:35修改过]

总得来说,Scala只是有很多好语言特性而已,只是语言范畴,它所带来的只是描述上的改变,当然它相对于Java,多了函数式方式的描述,同时也引入了相关思维。

拥有特性不代表能用特性时就用特性,“能用则用”是很危险的,我们应该“需用则用”,Scala也只是提供多种可选择方案而已,它完全可以像Java一样编程。

就业方向我现在也是Java,因为相关岗位多,但Scala却是我向新领域探索的语言,它以简单方式遵循着我的思想在跑,而不是我遵循着它在跑。

作者回复了这个问题,那只是个私人邮件,表达了一些对scala的不满
http://eng.yammer.com/blog/2011/11/30/scala-at-yammer.html

正在学习scala,学习其思想。