关于编程语言的一些思考

这几年脚本语言一直在大行其道,Python,Ruby,JavaScript等语言几乎被用到了行业的各个方面。尤其是JavaScript,在Node.js之后几乎成了统御前后端的万能语言。

然而正是在这个大背景下,也有非常多反其道而行的大公司。比如Google对JavaScript似乎一直不满意,他们想了很多办法尽可能不去用JavaScript。一开始出现了GWT,目的是把Java编译成JavaScript,后来又出了一个Dart语言。Apple也在这个时间推出了Swift,比起Objective C的各种动态特性,Swift语言本身就显得静态了许多,也严格了许多。

我虽然从业只有2年多一点,但在这些时间里面有幸涉猎了各种语言,我个人认为,对于一般公司而言,比较适合那些有静态类型检查,语法也偏静态,并且是编译型的语言做开发。这是因为,虽然脚本型语言在初期开发时有快速灵活的优势,但维护成本却非常的高,而且代码腐烂的速度也会很快。可以说“灵活”这个词,在编程语言里面接近于“坑”的代名词。

我最不喜欢脚本型语言的一点是,没有静态类型检查。这会对后期维护产生非常多的问题。因为缺少静态类型检查,所以在函数声明时无法声明参数类型,也无法声明函数返回类型,比如:

当你看到这个函数的声明时,如果没有文档和注释,你无从得知这个函数能接收那些参数,它的返回值是什么样的。而如果有callback就更加悲剧,因为你更不知道callback里面能有什么入参。你唯一能做的就是阅读源码。

相比而言,有静态类型检查的语言就好多了。比如对等的Swift代码:

虽然它的声明看起来很啰嗦,但你可以不用看函数体,甚至不用看文档(如果函数命名、变量命名很好的话)就能猜出需要传哪些类型的参数,callback会有怎么样的入参,函数将返回什么etc.

正因脚本语言没有类型检查,不用写返回类型等等特性,导致编辑器和IDE很难做错误提示,并且这些语言多是解释型语言,没有编译器的编译检测,很多错误只能通过单元测试和运行过程中才能发现。

所以我认为,脚本类的语言,对于开发者的要求非常之高。不但需要尽可能地多写单元测试,还要很好地维护文档。这对一个拥有良好习惯的编程高手来说,并不是一个大问题。但软件开发很少有一个大牛从头到尾开发一个软件,更没有一个软件从头到尾都是由一个大牛维护的。软件工程里面最不可缺少的就是程序员之间的交流合作。而对于普通公司的普通团队来说,根本不可能保证不同时期的所有的team member都是习惯良好的一流高手。而人又是有惰性的,如果一件事情可以不做,则很多人会选择尽量不做。于是用脚本类语言开发的程序渐渐地会变成一个一个大坑——因为单元测试不是强制的,所以可以不写;因为程序没有文档也能运行,所以可以不写;因为不做类型判断程序也能运行,所以就不做判断。

所以在管理一般性的团队的时候,重要的并不是怎么调动大家的灵活性进行开发,而是怎样让事情变得规范化和可控。比如多数团队都会制定一个Code Style来强制规范组员代码的风格(但由于不遵守代码规范的代码也能运行,所以经常会碰到违反的情况,这时候就需要代码审查,但是审查人也会有偷懒的时候,所以Code Style很多时候也不能完全规范化代码)。而强制性最高的,莫过于拥有类型检查的编译器了——因为如果不能通过编译器的检查,代码根本就不能运行,所以大家只能老老实实地遵守编译器规范,比如该写接口的时候写接口,该用泛型的时候用泛型,函数传参类型等等就更不在话下了。因此,这种规范较多的语言,在整体水平一般的团队中,使用起来比较方便,也更容易“横向扩展(即用较低的价格雇佣一些不完美的程序员来堆砌代码)”。

最近的一些新语言发展趋势,也证明了那些拥有静态类型检测的语言将会是业界新宠。比如Go, Scala, Swift, Dart这样的语言,看起来都非常接近,他们有静态类型检测,也偏向于静态,又增加了类型推导,从而不像Java那样啰嗦,也加了函数式编程的特性,引入新的并发模型等等。而脚本类的语言,则在产品原型开发、小型脚本编写中比较方便,在大型项目中就显得有点坑了。

1 Comment

  • 胡瀚森

    2014 年 12 月 20 日 at 11:46 回复

    Type deduction is a great stuff, actually enhances coding efficiency of static type languages.

Post a Comment