C 语言工程师转做 Scala 需要补充哪些知识？

首先从题主找工作的目标出发，目光不需要放在以Scala为主要编程语言的公司。国内所有应用Spark、Play、Spray等以Scala为主要开发语言的开源系统的公司都需要Scala人才。应用大型开源软件时，势必需要足够的人才储备去理解相关软件架构以便进行调优、调试、改造、修复。以Spark为例，BAT三家、Intel、MSRA、亚信、华为、爱奇艺等等目前应该都有相关需求。

其次从长期的学习路线出发说一说。我一直认为Scala是一门以FP为目的、以OOP为手段诱骗Java程序员上FP贼船的过渡型语言 :-)

很多人都知道Martin Odersky是Java标准委员会的成员，是Java泛型的作者，有第一手的工业经验；但他的另一个身份却并不广泛为人所知：Martin Odersky也是程序语言大神、Pascal作者、图灵奖获得者Niklaus Wirth的嫡传弟子。可以说Martin是业内罕有的工业学术两手抓，两手都很硬的人物。一方面他相信在现在分布式、并行、并发横行的时代，FP必然是未来的大趋势，另一方面他也深知当前的工业界仍然被命令式OOP语言所垄断。再加上在Java标准委员会的时候他就对Java的设计非常不爽，于是才有了Scala这门Java done right的FP、OOP融合型语言。

对于初学Scala的Java程序员来说，Scala首先是一个简洁版的Java（无论是语法层面还是语言标准文档长度方面）。前几天看到一个对比Swift和Object-C的笑话，放在这里也适用：在Java里你要说“I am laughing out loudly”，在Scala里你只需要说“LOL”。但等你上钩之后就会发现，虽然Java里的各种OOP手法在Scala里都能用，而且更简洁，但Scala的各种标准库和最佳实践统统走的都是FP路线，于是你自然而然地开始学习FP的知识。当然也有很多人到了这一步就放弃了。

再接下来，就会有人产生“Scala是少数复杂性堪比C++的语言”的想法。这里我要从两点做辩护。第一，Scala的复杂性是正交特性乘积的结果，而C++的复杂性是各种ad-hoc补丁累加的结果。其直接表现便是两门语言specification的长度Scala 2.9 191页，手头一份C++ 11的working draft则足足有1328页。第二，JVM并不是为函数式语言设计的，虽然近年来为函数式语言作出了一些改进，但还是有很多局限。为了弥合JVM与上层函数式语言之间的差异，Scala在设计上可谓戴着枷锁跳舞，做出了诸多妥协。例如利用ClassTag提供运行时类型、REPL中十分怪异地将每行代码单独编译成一个object（2.11中可以编译为class）等等。同时，为了融合FP和OOP，Scala也为OOP做出了一定的牺牲，例如类型推导无法覆盖函数参数类型等等。这就造成了一个问题：对于熟悉ML、Haskell、OCaml等函数式语言的人来说，Scala看上去十分熟悉，很多语言特性都可以简单地映射到现有函数式语言上去（例如implicit与type class，case class与代数类型），上手十分容易；另一方面，对于没有接触过FP的初学者来说，这些噪音使得用Scala学习FP可能还不如清空脑袋中的OOP知识，直接学习ML来得轻松愉快。但是不得不说，Martin虽然戴着枷锁，Scala这套舞仍然跳得十分出色，虽然不得不引入一些噪音，但已经极力将之控制到最小范围了。

所以从长期来看，个人认为学习一门正宗的静态强类型函数式语言（比如ML）可以更容易地将Scala中为适配JVM而变形的FP语言特性还原到其原初的朴素形态，从而大大加快、加深对Scala的理解。在此推荐Coursera上的Programming Languages课程，该课程以Standard ML、Racket（一种Scheme方言）、Ruby为例探讨了不同编程范式的程序语言的种种。我从SML的那部分课程收获颇丰。

　　　　　　　　　　　　　 查看评论 回复