这几年脚本语言一直在大行其道，Python，Ruby，JavaScript等语言几乎被用到了行业的各个方面。尤其是JavaScript，在Node.js之后几乎成了统御前后端的万能语言。
然而正是在这个大背景下，也有非常多反其道而行的大公司。比如Google对JavaScript似乎一直不满意，他们想了很多办法尽可能不去用JavaScript。一开始出现了GWT，目的是把Java编译成JavaScript，后来又出了一个Dart语言。Apple也在这个时间推出了Swift，比起Objective C的各种动态特性，Swift语言本身就显得静态了许多，也严格了许多。
我虽然从业只有2年多一点，但在这些时间里面有幸涉猎了各种语言，我个人认为，对于一般公司而言，比较适合那些有静态类型检查，语法也偏静态，并且是编译型的语言做开发。这是因为，虽然脚本型语言在初期开发时有快速灵活的优势，但维护成本却非常的高，而且代码腐烂的速度也会很快。可以说“灵活”这个词，在编程语言里面接近于“坑”的代名词。
我最不喜欢脚本型语言的一点是，没有静态类型检查。这会对后期维护产生非常多的问题。因为缺少静态类型检查，所以在函数声明时无法声明参数类型，也无法声明函数返回类型，比如：
function doStuff(a, b, callback){...}
当你看到这个函数的声明时，如果没有文档和注释，你无从得知这个函数能接收那些参数，它的返回值是什么样的。而如果有callback就更加悲剧，因为你更不知道callback里面能有什么入参。你唯一能做的就是阅读源码。
相比而言，有静态类型检查的语言就好多了。比如对等的Swift代码：
func doStuff(a:Int, b:Int, callback:(Int)->Void)->Bool {
...
}
虽然它的声明看起来很啰嗦，但你可以不用看函数体，甚至不用看文档（如果函数命名、变量命名很好的话）就能猜出需要传哪些类型的参数，callback会有怎么样的入参，函数将返回什么etc.
正因脚本语言没有类型检查，不用写返回类型等等特性，导致编辑器和IDE很难做错误提示，并且这些语言多是解释型语言，没有编译器的编译检测，很多错误只能通过单元测试和运行过程中才能发现。
所以我认为，脚本类的语言，对于开发者的要求非常之高。不但需要尽可能地多写单元测试，还要很好地维护文档。这对一个拥有良好习惯的编程高手来说，并不是一个大问题。但软件开发很少有一个大牛从头到尾开发一个软件，更没有一个软件从头到尾都是由一个大牛维护的。软件工程里面最不可缺少的就是程序员之间的交流合作。而对于普通公司的普通团队来说，根本不可能保证不同时期的所有的team member都是习惯良好的一流高手。而人又是有惰性的，如果一件事情可以不做，则很多人会选择尽量不做。于是用脚本类语言开发的程序渐渐地会变成一个一个大坑——因为单元测试不是强制的，所以可以不写；因为程序没有文档也能运行，所以可以不写；因为不做类型判断程序也能运行，所以就不做判断。
所以在管理一般性的团队的时候，重要的并不是怎么调动大家的灵活性进行开发，而是怎样让事情变得规范化和可控。比如多数团队都会制定一个Code Style来强制规范组员代码的风格（但由于不遵守代码规范的代码也能运行，所以经常会碰到违反的情况，这时候就需要代码审查，但是审查人也会有偷懒的时候，所以Code Style很多时候也不能完全规范化代码）。而强制性最高的，莫过于拥有类型检查的编译器了——因为如果不能通过编译器的检查，代码根本就不能运行，所以大家只能老老实实地遵守编译器规范，比如该写接口的时候写接口，该用泛型的时候用泛型，函数传参类型等等就更不在话下了。因此，这种规范较多的语言，在整体水平一般的团队中，使用起来比较方便，也更容易“横向扩展（即用较低的价格雇佣一些不完美的程序员来堆砌代码）”。
最近的一些新语言发展趋势，也证明了那些拥有静态类型检测的语言将会是业界新宠。比如Go, Scala, Swift, Dart这样的语言，看起来都非常接近，他们有静态类型检测，也偏向于静态，又增加了类型推导，从而不像Java那样啰嗦，也加了函数式编程的特性，引入新的并发模型等等。而脚本类的语言，则在产品原型开发、小型脚本编写中比较方便，在大型项目中就显得有点坑了。
