什么是腳本語言

　　很多人都會用一些“腳本語言”（scripting language），卻很少有人真正的知道到底什么是腳本語言。很多人用 shell 寫一些“腳本”來完成日常的任務，用 Perl 或者 sed 來處理一些文本文件，很多公司用“腳本”來跑它們的“build”。那么，到底什么是“腳本語言”與“非腳本語言”的區別呢？

　　首先我們來看看“腳本”這個概念是如何產生的。使用 Unix 系統的人都會敲入一些命令，而命令貌似都是“一次性”或者“可拋棄”的。然而不久，人們就發現自己在重復的敲入類似的命令，所以有人就發明了“腳本”這東西。它的設計初衷是“批量式”的執行命令，你在一個文件里把命令都寫進去，然后執行這個文件。可是不久人們就發現，這些命令行其實可以用更加聰明的方法構造，比如定義一些變量，或者根據系統類型的不同執行不同的命令。于是，人們為這腳本語言加入了變量，條件語句，數組，等等構造。“腳本語言”就這樣產生了。

　　然而人們卻沒有發現，其實他們根本就不需要腳本語言。因為腳本語言里面的這些結構，在任何一種“嚴肅”的程序語言（比如 Java，Scheme）里面，早就已經存在了。腳本語言的“優勢”，其實只在于它不需要事先“編譯”，它“調用程序”的時候，貌似可以少打幾個字。然而，這個優勢卻是非常不明顯的。你完全可以想一個自動的辦法，先調用編譯器，生成機器代碼，然后執行它。或者你可以選擇一種有解釋執行方式的“嚴肅語言” （比如 Scheme）。實際上，很多 Scheme 解釋器都會進行一定程度的“編譯”，有些編譯為字節碼，有些編譯為機器代碼，然后再執行。所以在這種情況下，“編譯性語言”與“解釋性語言”，幾乎沒有本質上的區別。

　　跟 Java 或者 Scheme 這樣的語言截然不同，“腳本語言”往往意味著異常拙劣的設計，因為它的設計初衷往往是目光短淺的。這些語言里面往往充滿了歷史遺留下來的各種臨時的 hack，幾乎沒有“原則”可言。然而，在當今現實的工程項目中，這種腳本卻占據了它們不該占有的地位。例如很多公司使用 shell 腳本來處理整個軟件的“build”過程或者測試過程，其實是相當錯誤的決定。因為一旦這種 shell 腳本日益擴展，就變得非常難以控制，經常出現一些莫名其妙的問題，卻找不到到底哪里出了問題。

　　我發現，“腳本語言”這個概念貌似在很多人的心目中根深蒂固了，仿佛他們頭腦里的程序設計原則，一遇到“寫腳本”這樣的任務就完全崩潰了似的。很多平時寫非常聰明的程序的人，到了需要處理“系統管理”任務的時候，就開始寫一些 shell 腳本，或者 Perl 腳本。他們寫這些腳本的時候，往往完全的忘記了程序設計的基本原則，例如“模塊化”，“抽象”等等。他們大量的使用“環境變量”一類的東西，仿佛處理系統管理就應該這樣做似的。

　　到后來，他們開始耗費大量的時間來處理腳本里面的錯誤，重復的犯同樣的，莫名奇妙的錯誤，卻始終沒有發現問題的罪魁禍首，其實是他們錯誤的認為自己需要“腳本語言”。

　　腳本語言，幾乎永遠是錯誤的決定。