近来工作的重心完全转到了数据工程上，几乎一点网站相关的东西都没有了。项目的主管老板受到他业界一位亲戚的安利，非常喜欢Scala；但由于我们公司绝大部分开发都是基于Python，就连数据相关的Spark项目也是直接上PySpark，这个拧巴的语言就一直没有被真正地推广过。不过Hadoop不像Spark那样对Python有原生API支持（支持力度大小暂且不论，但至少是亲儿子级的API），而我又正好遇到了一个需求，要直接调用Hadoop API来查找文件，就只好被迫在JVM语言里选一个。由于Spark几乎全是Scala写的，学习一下对二次开发有帮助；Scala和Java相比又多了一个REPL，至少可以交互式地尝试不熟悉的接口，于是我就又重新捡起了这个我并没有真正掌握过的语言。写了两个很简单的项目之后，在这里很简单地回顾一下我和Scala的一些经历，以及对Scala的一些想法——十分不严谨，也没有太多原创的内容……但是我懒，如果想不起我的一些论点和论据是从哪些大牛的言论里引用来的时候，就先不注明了——不过如果有人回复了哪些人提过相同的想法，我会再另加注明的，走过路过的各位还请轻拍。
对于Scala，我和它的缘分还得从大三时候说起。那时的我平时是以写Java为主的，但是因为大一时候编程入门课用的Scheme，对函数式编程有点初恋一样的情节，时常YY着有一天能在JVM这个工程级别的平台上写函数式的语言。
有一天Coursera上开了门课，马丁奥德司机大叔亲自上去讲课教大家用Scala，我就屁颠屁颠地入了坑，于是半个大三就成了白天在银行实（神）习（游），晚上在宿舍参加社团活动，半夜红着眼睛刷Scala作业的节奏，十分酸爽过瘾万分庆幸自己没有猝死……于是终于成就了我在Coursera上拿下的第一门，也是至今唯一一门课……
老人们总说，技多不压身，果然后来我去UCSB交换的时候，选的Programming Language这门课，上来教授就说，我们这课用Scala做实现——当时心里简直乐开花，完全就是感觉自己努力得像一个傻逼一样（其实并没有）终于有回报了一般。但是残酷的现实就是，Scala语言上的一丁点优势，完全撑不过两次作业，遇到课程大纲里真正的核心概念后就真是瞬间荡然无存。于是乎，这门课只能吭哧吭哧地面向作业里的Test case编程，马马虎虎地混了个及格。
毕业之后，我懵懵懂懂地开始作一个网站开发，由于做的内容偏运营统计相关，而且日常工作以维护为主，对后端其实一直没有形成很清楚的概念，就又开始YY着如果换一个语言或者平台，开发的时候有强类型支持，我会不会学得快一点——现在回想还真是蛮蠢的哈——当时的我还尝试过用Play来写网站，然而从来没有搞懂这一个巨兽级别的框架怎么上手。当然“巨兽”这个词用出来会有J2EE、SSH的老鸟要笑我，不过乃们想想我现在还只是Flask菜鸟，连Django都觉得复杂，两年前贸然挑战Play也真是可笑啊。
不过在几个月之后，用Flask从头开始撸了一个微型小网站出来，也就放下学一个新框架的执念了。特别是最近一年多以来，凭着闲暇时候读过的一些零零碎碎的博客，感觉自己也在慢慢反思什么语言才算得上称手好用，也渐渐感觉到，Scala里过多的语法特性，为了追求和DSL接近的一些设计，确实是非常值得商榷的。
我最不习惯的一个语言特性就是Scala在语法上不区分无参调用和一个变量。举一个简单的例子：
scala> def a = { print("Hello world") }
scala> val b = a
上面两行东西定义了一个函数a和一个变量b指向a。现在来调用一下，看看会有什么结果：
scala> a
Hello World
scala> b
// WTF
可以看到，在调用a的时候正确地输出了我们要的信息，但是在调用b的时候什么结果都没有。当然，这样的行为也并非所有人都不理解——例如习惯Ruby的筒子们应该非常清楚这是来自“面向对象”语言里的一种方法调用风格，叫做LISP-2，详情可以参阅松本大叔的《代码的未来》，简单来说就是，上面的那句val b = a，其实是把a函数的执行结果给了b，然后a并没有返回值，于是b也就只返回了一个空值，咩都看不到~
喜欢Scala的人把这样的设定说得十分美好，因为这样的设定方便把代码写得像自然语言，毕竟自然语言里不那么欢迎括号；但是用JS和Python的人上手这样的设定一般都很不习惯，因为这实在是有点含混不清的感觉——调用无参函数怎么就和一个变量长得一样呢。。。那还怎么获取对函数本身的引用？这里确实有一些方法可以达到类似的效果，但都和Scala的强类型设定多少有点冲突，我这里就不展开了，反正就是和括号玩游戏而已。对于非把编程语言写得和自然语言接近，这在领域特定语言里好像是个蛮受欢迎的课题，但原谅我不认为这是一个好趋势——毕竟自然语言是有很多歧义的，而编程语言里不应该有（这个观点可以算是来自王垠吧，是他众多观点里我非常认同的一条）。
还有，对于强类型设定的冲突，我想再顺便举一个例子：
scala> val l = List(1, 2, 3, 4, 5)
l: List[Int] = List(1, 2, 3, 4, 5)
scala> l.map(_ + 2)
res5: List[Int] = List(3, 4, 5, 6, 7)
scala> def a(x: Int) = x + 2
a: (x: Int)Int
scala> l.map(a)
res6: List[Int] = List(3, 4, 5, 6, 7)
scala> l.map(a _)
res7: List[Int] = List(3, 4, 5, 6, 7)
scala> l.map(a(_))
res8: List[Int] = List(3, 4, 5, 6, 7)
我上面举了四个例子的map调用：第一个是最华丽也是最被提倡的，可惜不是所有调用都能这么简单，于是我定义了一个函数来给所有的元素加2，同样的列表直接map这个函数也是可以的；但是问题是，我如果写了map(a(_))，还是可以map，这就非常不直观了——因为第一眼看上去，a(_)是一个调用的结果——但是实际上，下划线在Scala里有各种神奇的用法，这里就是其中之一，算是_ => a(_)的简写形式。下划线还不止于此，还能被用于类型匹配等其他方面——窃以为有点重载过度了，类型匹配里的下划线用法比这个场景合理一些。
还有一些阻碍其他语言程序员上手的设定，不过有一些确实是不得已的权衡，不太像是一些设计上本来可以避免的、甜得过度的语法糖。合理权衡的例子比如集合类的逆变和协变，是出于类型安全的考虑；还有一个我同事吐了很久的槽（因为他之前写Java），他不喜欢Scala代码里的包声明和路径不对应，我感觉应该是为了支持一些动态脚本的特性（Scala Script）而放宽的限制吧——但是话说回来，一个类型安全的语言真的应该支持这些脚本特性吗？或者其实没准这不是一个绕不开的坑，只是实现上没有做好？
总体上来说，Scala真的是一门非常非常神奇的语言，所有想得到想不到的特性都多少有些支持，单从这点来看，是非常独到的。但是支持的特性又多到出现了不得已的冲突，让整个语言看起来充满了复杂的设计和甜到忧伤的语法糖。如果我们真的以后会有更大规模使用的话，可能得提前做好准备，做一份详细的代码风格要求，否则估计到时候会满屏的缩写和咒符吧括弧笑。
最后招个人吧……如果有志同道合的数据工程师或者增长黑客想来新加坡就业的话请发简信 :)
