Scala种种信息--google地毯式搜索的收获

    去年对scala的研究中断于项目紧张时, 所以至今对scala的了解仅限于语法, 一些相关问题, 比如环境的搭建, 概念还是相当模糊, 今天突然兴起, 跑到网上乱搜了一通, 搜来一些信息, 权当为以后转攻scala做个铺垫吧.

    1. ide的选择: 至今用过的ide只有三种, eclipse, netbeans和文本编辑器(泛). eclipse 的scala插件一上手就觉得不爽, 代码补全能力几乎为零, 构建也慢. netbeans的scala插件在代码补全上很不错, 但是有些bug比较严重, 连续编译功能会时不时地崩溃, 代码编辑器上一片红, 非重启netbeans不能恢复, 这个足以让人无法忍受. 此外, 两者对scala类库的源码查看都比较雷, 居然尝试编译打开的源码文件, 结果也是一片大红, 非常影响心情. vim这类编辑器, 我一向只用来编写bash脚本, 从未试过在上面开发java/ruby之类的程序, 不好评价. intellij一向不怎么用, 据说scala插件不错, 但是编译用时比前面那两位还长.

    2. 开发环境: 从google上的情况看, 目前比较吃香的是SBT+JRebel 的组合, 再加上一个编辑器(ide). 由于sbt有持续编译功能, 其实用什么ide都不重要了, 即使vim又怎么样, 只要能有插件能显示项目视图, 一些简单的代码提示, 剩下的就让sbt去操心好了. JRebel算是我的一个新发现, 怪我孤陋寡闻了, 但它的特性的确让我眼前一亮, 只加载修改过的class文件, 让appserver上的程序继续跑而非重新加载, 是我三年前做梦都想要的功能. 有了jrebel, 即使scala编译的确较java慢又怎样, 我不用重新加载, 最后还是比你快得多. 此外一个附加bonus是, JRebel对scala的license是免费的, 对java则是US$365/licence*year(企业版). 其实, 即使不做scala项目, 我也很乐于在java项目里引进这个工具, 一年365美刀实在是个小数, 相对于浪费在程序员薪水上的投入来说.

    3. 开发框架: liftweb是我最先接触的, 因为它最有名, 有名到maven刚有scala的archetype, 就马上有了lift的archetype, 创建一个lift项目只是举手之劳, 甚至在还不知道lift为何物的时候. 但说实话liftweb确实比较复杂, 我跌跌撞撞跟着simple lift的tutorial完成了一个项目, 仍然对这个框架的作用机制一无所知, 感觉十分不爽. play framework是个不错的java框架, 由于它对scala的支持也相当强, 我会把它当作我的scala起步框架.

    4. 关于groovy: groovy的发明人对scala评价极高, 甚至说出"如果那时我就能见到scala, 那我很可能都不会去发明groovy"的话. 我也粗通一些groovy, 在我看来, 如纯粹作技术上的比拼, groovy几乎没有存在的必要, 只有那些非动态不可的场合才能保住它的一席之地. 但是行业的当前状况是java一家独大, groovy作为java的亲生嫡系, 接受度自然较高, 加上学习曲线几乎恒零(对于javaer来说), 短期前景还是在scala之上的. 不过我相信scala终将突破成见, 占据主流, 因为它在性能和语法上的优势实在是明显. groovy在我看来只适用于有简单计算的CRUD程序(如grails站点), 在性能敏感的领域groovy决无用武之地. 公司项目里有一个swing桌面程序, 一年前被一个家伙用groovy写了, 起初他还很得意地表示自己的选择是多么明智, 所需代码量是多么小. 但是当代码量无可避免地上升后(需求的细化需要越来越多的类), 性能差得一塌糊涂, 根本无法使用. 最后的结果居然是所有groovy代码被废, 整个程序须要用java重新写过. 相信如果当时采用scala来写这个swing程序, 无论是性能还是代码量都会令人满意的.

评论

2 楼 jeff312 2011-11-21  

如果没有被墙，scala官网上的资料已经很多。我对scala也是粗通，尚未做过真实的项目，如果要做web应用，选择liftweb或play框架起步当是首选。如果在已有框架上开发，用scala写service好了。

1 楼 桥下一粒砂 2011-10-24  

兄台，我对Scala也很感兴趣，不知道你有没什么学习资源分享一下？