什么是“脚本语言”

原文来自我的豆瓣日记，对垠神的博文的一些感触。
==================================

很多人都会用一些“脚本语言”（scripting language），却很少有人真正的知道到底什么是脚本语言。

其实编程语言只是程序员用来表达思想的工具，本就没有本质意义上的区别。他们的区别就在于表现形式上的不同。但表现形式就是更大程度上体现的是设计思想，而“脚本语言”的一般指导思想就是为了简化程序员工作，让程序员能够写出更为简单易用的代码，而不必按照非常严格的特殊规范来找一屁股的麻烦从而完成一个本来看似简单的事情。相反，某些“非脚本语言”因为考虑太过复杂臃肿，结果反而会被冷落一旁，这样的例子，不举也罢。

首先，脚本语言的产生就是为了更加简化程序员的工作的。Unix的shell script就是非常典型的脚本，可以通过联合各种命令来进行简化重复的操作；这其实就是在进行简单的抽象，而程序设计的基本思想就是抽象，更进一步，脚本逐渐融合进来了更多的能够方便抽象的东西，于是就成了脚本语言。

然后人们发现，脚本语言变得跟他们生活息息相关。虽然脚本里的这些结构，在任何一种“严肃”的程序语言（比如 Java，Scheme）里面早就已经存在了，而且设计得更加完善。但是“严肃”毕竟是严肃的，总有他的各种不可取之处，虽然脚本语言的执行期效率远小于“严肃”的语言，但是随着JIT等技术的加入，脚本语言也能够获得和“严肃”语言一般的执行效率。

很多人把Scheme为“脚本语言”，因为它可以解释执行，然而是否能够“解释执行”其实并不是区分“非脚本”和“脚本”的标准。这跟Java这样的不能够“解释执行”语言不同，Scheme的设计者比起Java的设计者，造诣更加深厚，所以他们对Java的一些设计错误，看得非常清楚。因为某些解释“脚本”语言也有编译期，而很多编译型语言也可以解释执行，因为很多解释器都会进行一定程度上的“编译”，有些编译为字节码，有些编译为机器代码，然后再执行。所以，在这种情况下，通常人们所谓的“编译性语言”与“解释性语言”，几乎没有本质上的区别，因为你看到的“解释器”，不过是自动的先编译再执行。

跟Java这样的语言截然不同，“脚本语言”往往意味着更加人性化的设计，它的设计初衷往往是更注重考虑程序员的想法/习惯，而非语言要怎么来“约束”程序员的自由。这些语言里面往往充满着继承自历史的各种hack，各处体现着黑客精神。Java的设计有很多问题，跟“脚本语言”有着天壤之别，通过强制性的语法约束和编译检查来硬性改变程序员的习惯这种反人类的方式来对计算机进行妥协是非常讨厌的！然而，在当今现实的工程项目中，由于很多公司和专家的吹捧，Java却占据着它不该占有的地位。例如很多公司使用Java来实现某些大型项目，其实是相当错误的决定。因为一旦这种方式日益持久，程序员就会变得陷入到Java的语法纠结中去而变得思维单一脾气暴躁，经常出现一些莫名其妙的问题，却反而会觉得是自己能力不够。ED们大量使用Java来完成他们的项目，其实也是一个历史遗留的错误。所以，不要以为看起来ED们很赚钱就以为Java是什么好东西！

你完全可以在脚本里面使用通常的程序设计技巧，比如函数等，甚至如果要写一个完善的大型项目也能够利用到足够多的抽象，或者你认为简单的模式。可是我发现，很多人头脑里面清晰的程序设计原则，一遇到Java这个东西就完全崩溃了似的，他们仿佛认为程序就该长得是Java那个样子，到处都要死板严格，遵守着典型的ED式程序设计风格但往往完全忘记了自己亲身的体验，甚至还会有一些自虐的倾向，把一个简单的东西实现为一系列的复杂的严格的表面上以扩展为目的却到处都是过度设计的模式。他们认为的“抽象”往往成了反道行之的做法。到处使用约束以确保自己不会出现错误，其实这才是他们犯的最大的错误。到后来，他们开始耗费大量的时间来进行重构，来解决“过度约束”给他们带来的问题而再次进行约束，却始终没有发现问题的罪魁祸首其实就是他们错误的认为自己需要“约束”，然后认为就要限制自己的思维来符合计算机的习惯。

所以我认为脚本语言是一个好东西，有它永远的存在价值。而我们应该尽一切可能来避免使用Java这种语言。在没有办法的情况下（比如老板要求），也应该在使用Java前想想通常的程序设计思维。