(這篇文章發表在IEEE計算機雜志1998年3月刊上)
摘要：
Perl和Tcl等腳本語言代表一種與c或JavaTM為代表的系統程序設計語言完全不同的編程形式。腳本語言為"膠著"應用程序而設計，它使用無類型方法來實現高級編程和比系統程序設計語言更快的發展應用。計算機速度的增長和混合應用的改變使腳本語言在今后的應用中越來越重要。
關鍵字：
組件框架，面向對象編程，腳本，強類型，系統編程
1.簡介
在過去的十五年里，人們編寫計算機程序的方法發生了根本的轉變。這種轉變是從c或c++等系統程序設計語言到Perl或Tcl等腳本語言的過渡。雖然很多人參與了轉變，卻很少有人意識到它的發生，更不用說知道為什么會發生。這篇文章是我關于為什么在下個世紀腳本語言可以比系統程序設計語言更好的處理許多編程工作的一點看法。
與系統程序設計語言相比,不同的腳本語言為不同的工作而設計，這導致了語言間的根本不同。系統程序設計語言起源于像內存字等最初期的計算機元素,它為建立數據結構和算法而創建。相反的，腳本語言為膠著而設計：他們假設已經存在一套強大的組件，而它主要是把組件連在一起。系統程序設計語言使用強類型定義來幫助處理復雜事務，而腳本語言使用無類型定義來簡化組件間的聯系,并提供快速應用開發.
腳本語言和系統程序設計語言互為補充，并且二十世紀六十年代以來的大多數主要的計算機平臺都同時提供這兩種類型的語言。這些語言在組件框架中有著典型的應用：組件由系統程序設計語言創建，并由腳本語言組合在一起。然而，速度更快的機器，更好的腳本語言，圖形用戶界面和組件構造重要性的不斷提高，因特網的發展等發展趨勢大大提高了腳本語言的應用。在今后的十年中，這種趨勢將繼續，而且越來越多的完全使用腳本語言和系統程序設計語言書寫的應用程序將主要用來創建組件。
2.系統程序設計語言
為了理解腳本語言和系統程序設計語言的不同,最好先了解一下系統程序設計語言是如何發展的.系統程序設計語言是作為除匯編語言外的另一種選擇而引入的.在匯編語言里,實際上機器的每一個細節都被反映在程序里.每個狀態代表一個簡單的機器指令,而程序員必須處理像寄存器分配和程序調用順序等低層細節.因此,用匯編語言編寫和維持大型程序是很困難的.
二十世紀五十年代后期像Lisp,Fortran和Algol等高層語言開始出現.這些語言里的狀態和機器指令不再完全一致,編譯程序把過程程序中的每個狀態翻譯成一系列二進制指令.經過一段時間,一系列系統程序設計語言包括PL/1,Pascal,C,C++和Java由Algol發展而來.系統程序設計語言沒有匯編語言的效率高,但他們使應用程序更快的發展起來,因此,系統程序設計語言在大型應用項目的發展中幾乎完全取代了匯編語言.
系統程序設計語言與匯編語言在兩個方面有所不同:它是高層語言并且是強類型."高層"意味著很多細節被自動處理以便編程人員可以寫更少的代碼而做同樣的工作.例如：
★編譯程序處理寄存器分配,所以編程人員不需要寫代碼來在寄存器和內存間轉移數據
★自動設計程序調用順序:編程人員不需要擔心調用棧之間的參數轉移
★編程人員可以使用像while和if等簡單的關鍵字來控制結構,編譯器執行所有的指令細節來完成控制結構
平均每行系統程序設計語言代碼翻譯成大約五條機器指令,與此相比,每行匯編語言代碼翻譯成一條機器指令(由5個不同的人寫的8個c文件的非正式分析中,我發現這個比率為每行3到7條指令;Capers Jones從大量語言的研究中發現對于一個給定的工作,匯編語言需要的代碼長度大約是系統程序設計語言代碼長度的3-6倍)不管是什么語言,編程人員每年可以寫大體上相同數量的代碼行,因此,系統程序設計語言允許用比匯編語言快得多的語言寫應用程序.
匯編語言和系統程序設計語言的第二個不同是類型設置.我使用"類型"來說明信息的意義在它被使用前就被特殊化.在強類型語言中編程人員聲明如何使用每條信息,并避免此信息被用于其他方式.在弱類型語言中信息應用是沒有優先權限制:信息的意思完全由它的使用方法確定,而不是任何初始約定.
現代計算機基本上是無類型的:內存中的任何字對任何類型的值比如整型,浮點數,指針或結構體都是有效的.值的意思由它的使用方法確定:如果指向一個內存字,那么他就被認為是結構體;如果一個字涉及一個整型加結構體,那么他就被認為是整型,如此等等.相同的字在不同的時間可用于不同的方法.
與此相反,現在的系統程序設計語言是強類型定義的.例如:
★系統程序設計語言中的每個變量都必須被聲明為整型或指針或字符串等特殊類型,并且必須用于適合這種類型變量的方法
★數據與代碼完全分離:創建新的代碼很困難或根本不可能.
★變量可以集中在結構體中或者定義好的子結構體和過程或方法的對象中以便于使用;一種類型的對象不能用于期待其他類型對象處.
確定類型由幾個好處.第一,聲明變量如何使用使大型程序更易于管理并區分那些必須被分別對待的變量.第二,編譯器可以利用類型信息來偵測某些類型的錯誤,比如,試圖把一個浮點值作為一個指針.第三,定義類型能使編譯器更好的執行特殊代碼.例如,如果編譯器知道一個變量總是對整型值有效,那么他就可以產生一個整型指令來操縱這個變量;如果編譯器不知道變量的類型,那么他就必須產生額外的指令在運行時檢查變量類型.
總之,系統程序設計語言被設計來處理與匯編語言相同的工作,即隨機地產生請求.系統程序設計語言比匯編語言層次更高,類型更強.這就使請求產生更迅速并且處理更容易,除了在運行時有一點損失,圖示1是匯編語言和其他幾種系統程序設計語言的比較.
3.腳本語言
腳本語言,像Perl,Python,Rexx,Tcl,Visual Basic和Unix shells代表了與系統程序設計語言完全不同的編程.腳本語言假設已經存在了一系列由其他語言寫成的有用的組件.腳本語言不希望隨機地產生請求,他希望主要是把組件接在一起.例如,Tcl和Visual Basic可以被用于在屏幕上安排一系列用戶圖形控制,而Unix shells scripts被用于把過濾程序集合入管道.腳本語言常用于擴展組件特性,但他們很少用于復雜的算法和數據結構;這些東西常由組件提供.腳本語言有時涉及膠著語言或系統整體語言.
為了簡化連接組件的工作,腳本語言被設計為無類型的:所有的東西無論是看起來還是使用起來都是完全一樣的,因此他們可以互換.例如,在Tcl或Visual Basic中一個變量可以一會兒處理字符串,一會兒又處理整型.代碼和數據也常可互換,因此,可以用一個程序寫另一個程序,然后高速執行,腳本語言一般是面向字符的,因為它為許多不同的事物提供了一致的描述.
無類型語言使組件更容易連在一起.在使用時沒有優先級限制,并且所有的組件及其值都用統一的方式描述.除此之外,任何組件和值都可以在任何情況下使用;為某一目的而設計的組件可以被用于設計者完全沒有預見過的完全不同的目的.例如,在Unix shells中,所有的過濾程序從輸入讀入字節流,并把字節組成的字符串寫入輸出;任何兩個程序都可以通過把一個的輸出連到另一個的輸入而把兩者聯系起來.
下面的shell命令把三個過濾堆在一起來計算選中區域中包含單詞"scripting" 的行數:
select | grep scripting | wc
select程序讀入當前顯示選中的文本并把它輸出;grep程序讀取輸入并把包含"scripting"的行輸出;wc程序對輸入的行數求和.其中的每個 程序都可以用于許多其他情況來做不同的工作.
系統程序設計語言的強類型本質上阻止重用.類型鼓勵編程人員創建包含不相容接口的類型("接口很好,接口越多越好").每個接口需要特別類型的對象,而編譯器不允許接口使用任何其他類型的對象,即使那樣有用.為了使用一個已經存在的接口的新的對象,就必須寫轉換代碼以便在對象的類型和接口期望的類型間進行翻譯.這反過來又需要重編譯部分或全部分布式二進制形式的應用程序,在普通情況下這是不可能的.
為了能看出無類型語言的優點,考慮下面的Tcl命令:
button .b -text Hello! -font {Times 16} -command {puts hello}
這個命令創建了一個新的按鈕來顯示16點Times字體,當用戶敲擊控制鍵時顯示一段小的信息.它把六種不同的類型混合成一個單一的狀態:一個命令名(button),一個按鈕控制(.b),所有權名字(-text, -font, 和-command),簡單字符串(Hello! 和hello),包含鉛字名(Times)及字點大小(16)的字體名(Times 16)和Tcl腳本(puts hello).Tcl代表所有這些非正式字符串.在這個例子中可以在任何一個命令中為屬性賦值,而未賦值的屬性使用給定的缺省值.在這個例子中20個以上的屬性是不特別賦值的.
同樣的例子在Java中用兩種方法執行時需要7行代碼.使用C++和微軟基本類（MFC）需要三個過程25行代碼,在微軟基本類中僅僅設置字體就需要幾行代碼:
CFont *fontPtr = new CFont();
fontPtr->CreateFont(16, 0, 0,0,700, 0, 0, 0, ANSI_CHARSET,
OUT_DEFAULT_PRECIS,CLIP_DEFAULT_PRECIS, DEFAULT_QUALITY,
DEFAULT_PITCH|FF_DONTCARE, "Times New Roman");
buttonPtr->SetFont(fontPtr);
大部分代碼是由強類型造成的.為了設置按鈕字體,必須運用SetFont方法,但這個方法必須通過指針傳給CFont對象,這反過來需要聲明和初始化一個新的對象.為了初始化CFont對象必須喚醒它的CreateFont 方法,但CreateFont有一個需要14個特殊化引數的固定接口.在Tcl中字體(Times鉛字,16點)的基本特征不用聲明或轉換就可以立即使用.另外,Tcl允許在創建按鈕的命令中直接包含按鈕行為,而C++和Java中需要把它放在單獨聲明的方法中.
(實際上可以用隱藏基本語言的復雜性的圖形開發環境處理一個像這樣的不重要的例子:用戶在表中輸入合適的值,而開發環境輸出代碼.然而,在更多復雜情況像按計劃產生合適值或接口的條件任務中開發人員必須在基本語言下編寫代碼)
這可能看起來腳本語言的無類型特性不能發現錯誤,但實際上腳本語言和系統程序設計語言一樣安全.例如在上面的按鈕例子中如果字體大小被置成非整型字符串,就像xyz,那么就會出現錯誤.不同的是當一個值被使用時腳本語言在最后一刻進行錯誤檢查,而強類型在編譯時發現錯誤這就避免了運行時的檢查.然而提高效率的代價是限制信息如何使用:這導致了更多的代碼和更不易改變的程序.
腳本語言和系統程序設計語言的另一個重要不同是腳本語言是被解釋而系統程序設計語言是被編譯.被解釋的語言由于沒有編譯時間而提供快速的轉換.通過允許用戶運行時編寫應用程序,解釋器使.應用程序更加靈活,例如,許多整體線路的綜合分析工具,包括Tcl解釋器;程序用戶編寫Tcl 腳本來使他們的設計具體化并控制工具操作.通過快速設計代碼解釋器可以實現強大的功能.例如,一個基于Tcl的網頁瀏覽器可以通過把網頁中的HTML轉換為使用一些常規表達替代物的Tcl腳本,從而從語法上分析網頁然后執行腳本把頁面翻譯顯示在屏幕上.
腳本語言不如系統程序設計語言效率高,部分是因為他們使用解釋器而不是編譯器,而且因為他們基本組件的選擇標準是功能強大和易于使用而不是有效地對應基本硬件.例如,腳本語言經常使用長度可變的字符串,而同樣的情況下系統程序設計語言使用對應一個機器字的二進制值;腳本語言經常使用哈希表,而系統程序設計語言使用變址陣列.
幸運的是,腳本語言的性能不經常是一個主要的問題.腳本語言應用程序通常比系統程序設計語言的應用程序要小,并且腳本應用程序的執行受組件執行的支配,而這些組件是系統程序設計語言提供的典型工具.
腳本語言比系統程序設計語言更高級,平均一個指令可以做更多的工作.一個典型的腳本語言指令執行成百上千條機器指令,而一個典型的系統程序設計語言指令執行大約五條機器指令(參圖一).部分不同是因為腳本語言使用翻譯器,這不如系統程序設計語言中被編譯的代碼.但是主要的不同是因為腳本語言的初期操作有更強大的功能.例如,Perl中喚醒一個常規表達替代和喚醒一個整型加法一樣簡單.在Tcl中,變量會有與它相聯系的圖標,因此,設置變量會導致側面影響.例如,一個圖標可能會被用于保持變量的值在屏幕上持續更新.
表1.表的每行描述了被執行了兩遍的應用程序,一遍使用系統程序設計語言,像C或Java,一遍使用腳本語言,像Tcl.代碼率列給出了兩個應用程序的代碼行率(>1意味著系統編程語言需要更多的代碼),作用率列給出了開發率.在大多數情況下兩個版本由不同的開發者執行.表中的信息由comp.lang.tcl新聞組中對文章進行答復的不同人提供。.
由于上面描述的特性,腳本語言允許基于膠著的應用程序的快速發展.表1提供了有趣的支持.它描述了幾個在系統程序設計語言下執行后又在腳本語言中重新執行的應用程序,或反過來也是一樣的.
在每種情況下腳本版本都比系統編程版本需要更少的代碼和更短的開發時間,不同點的變化從2到60.腳本語言第一次執行時好處不顯著,這使人聯想到任何在第一次執行經驗上的重執行都會更好,而腳本和系統編程的真正不同相差5到10倍,而不是表中的極端點.腳本的好處同樣依賴于應用程序.在表中的最后一個例子中,應用程序的圖形用戶界面部分是基于膠著的,而模擬裝置部分卻不是;這可能解釋為什么腳本應用程序不如其他應用程序獲益多.
總之,腳本語言被設計成膠著應用程序,他們提供比匯編或系統程序設計語言更高層的編程,比系統程序設計語言更弱的類型,和解譯后的開發環境.腳本語言犧牲執行速度來提高開發速度.
4.不同的任務,不同的工具
腳本語言不是系統程序設計語言的替代品,反過來也一樣.他們各自適合不同類型的工作.把膠著和系統合為一體,應用程序可以比腳本語言快5-10倍;系統程序設計語言將需要大量復本和轉換代碼來連接各塊.而這直接使用腳本語言.對于復雜的算法和數據結構,系統程序設計語言的強類型使程序更易于管理.執行速度是關鍵.系統程序設計語言可以比腳本語言運行快10-20倍,因為它產生更少的運行時檢查.
在決定是否使用腳本語言或系統程序設計語言處理一項特殊任務時考慮以下問題:
★應用程序的主要工作是否是把已經存在的組件聯系起來
★應用程序是否要操縱不同種類類型的事物
★應用程序是否包含圖形用戶界面
★應用程序是否做大量字符串操作
★應用程序函數是否能快速解決問題
★應用程序是否需要可擴展
如果這些問題回答"是"就表明這個應用程序使用腳本語言會更好.另一方面,如果對下面的問題回答"是"就表明系統程序設計語言更適合這個應用程序：
★應用程序是否執行復雜的算法或數據結構
★應用程序是否操縱大量數據集(像圖像中的所有像素)因而執行速度很重要
★應用程序的函數是否已經定義好,并且很少改動
在過去的30年中,大多數主要的計算機平臺同時提供系統編程和腳本語言。例如，第一個腳本語言雖然粗糙，卻是一個JCL(作業控制語言),它被用于在OS/360中把工作等級按順序排好。個別工作等級由PL1,Fortran或匯編語言書寫，那時是系統程序設計語言。在二十世紀八十年代時Unix機器上，c被用于系統編程而sh,csh等殼編程被用于腳本。在二十世紀九十年代的PC時代里，c和c++被用于系統編程e而Visual Basic用于腳本。在現在已基本成形的網絡時代中，Java被用于系統編程而像JavaScript , Perl和Tcl等語言被用于腳本。
腳本和系統編程是共生的，共同使用，他們能產生格外強大的編程環境：系統程序設計語言用于產生令人興奮的組件，然后用腳本語言把他們組裝起來。例如，Visual Basic的主要吸引力是系統編程者可以用c編寫ActiveX組件，而不太老練的編程者可以在Visual Basic應用中使用這些組件。在Unix下編寫用于喚醒用c編寫的應用程序的殼腳本很容易。Tcl普及的一個原因是可以編寫執行新命令的c代碼來擴展該語言的能力。
5．腳本呈上升趨勢
腳本語言已經存在了很長時間，但最近幾年幾個因素的綜合結果使它的重要性提高了。最重要的因素是應用程序綜合向膠著應用程序發展的變換。這種變換的三個實例是圖形用戶界面，因特網和組件框架。
圖形用戶界面出現于二十世紀八十年代早期，并在二十世紀八十年代晚期得以普及。在許多編程項目中圖形用戶界面占了一半甚至更多的比重。圖形用戶界面基于膠著應用：他的目標不是創建新的功能，而是把圖形控制集合和應用程序內部函數聯系起來。我不擔心任何快速發展的環境因為圖形用戶界面基于系統程序設計語言，不論是Windows環境,Macintosh Toolbox或Unix Mctif，圖形用戶界面基于c或c++等已被證明難以掌握,使用不靈活，生成結果不靈活的語言。一些這樣的系統有很好的圖形工具來設計屏幕輸出并隱藏基本語言，而一旦設計者不得不編寫代碼時一切變得困難起來，像為接口元素提供行為。所有好的快速開發圖形用戶界面環境都基于腳本語言：Visual Basic，Hyperlard和Tcl/tk，隨著圖形用戶界面的普及，腳本語言也越來越流行。
因特網的增長也使腳本語言變得大眾化。因特網只是一種膠著工具，它不創建任何新的計算結果或數據；它只是簡單的把大量已經存在的事物聯系起來。因特網編程工作的完美工作之一是讓所有連接的組件在一起工作，像腳本語言。例如：Perl 因編寫CGI腳本而流行，JavaScript因編寫網頁而流行。
基于腳本的第三個例子是組件框架，像ActiveX,OpenDoc和JavaBeans。雖然系統程序設計語言可以很好的創建組件，但腳本更適合組裝組件到應用程序中。沒有一個好的腳本語言來操縱組件，組件框架的大部分功能就都沒有了。這可以部分解釋為什么組件框架在個人電腦上（Visual Basic提供了方便的腳本工具）比在像Unix/CORBA等組件框架中不包含腳本的平臺上更成功.
腳本語言繼續普及的另一個原因是腳本技術的提高。現代腳本語言像Tcl和Perl離早期腳本語言像JCL的公開宣布已經很遠。例如，JCL不提供基本反復而早期Unix外殼不提供過程，即使在今天，腳本技術仍然相對不成熟。例如，Visual Basic不是真正的腳本語言：它最初執行像一個簡單的系統程序設計語言，然后修改使之更適合腳本。以后的腳本語言將比現在使用的更好。
腳本技術得益于計算機硬件的加速發展。過去常常用系統程序設計語言在復雜的應用程序中獲得可接受的執行。某些情況下甚至系統程序設計語言也不夠有效，因此不得不用匯編編寫應用程序。然而，今天的機器比1980年的快100-500倍，并且仍在繼續以每18個月翻一番的速度增長。今天，許多應用程序可以用解釋后的程序執行，并且仍然有出色的執行。例如，Tcl腳本可以操縱幾千個對象同時提供好的相互響應。由于計算機速度的不斷提高，腳本將對越來越大的應用程序產生吸引力。
腳本語言應用的不斷增長最終導致編程群體的改變.二十年前大多數編程者是大型項目的熟練的編程人員.那個時代的編程人員需要花幾個月的時間掌握一門語言和它的編程環境,系統程序設計語言就是為這些人設計的.然而,自從個人電腦出現以后,越來越多的非專業編程者加入到編程者的行列.對這些人來說,編程不是他們的主要工作,而只是他們偶爾用來幫助他們工作的工具.偶然編程的例子是簡單的數據庫查詢或者是巨大的擴展片.偶然編程者不希望花幾個月的時間學習系統程序設計語言但他們可以花幾個小時的時間學到足夠的腳本語言知識來寫出有用的代碼.由于腳本語言由簡單的句法并且省略了對象線程等復雜的特性,因而它比系統程序設計語言要容易學.例如,比較Visual Basic和Visual C++,很少有偶爾編程者會選擇Visual C++,而大部分會用Visual Basic建立有用的應用程序.
即使在今天,用腳本語言編寫的應用程序的數目也遠多于用系統程序設計語言編寫的應用程序的數目.在Unix系統中有比C程序更多的外部腳本,而在Windows下Visual Basic的編程者和應用程序都比C或C++的要多.當然,多數大型和廣泛使用的應用程序都是用系統程序設計語言寫成的,所以,如果比較代碼總行數或是建立的副本數,則系統程序設計語言略勝一籌.不管怎么樣,腳本語言已經是應用程序開發的主動力,并且今后它的市場份額會繼續提高.
6.對象的作用
腳本語言在編程語言和軟件工程中通常被專家忽視.取而代之,他們更注重像C++和Java等面向對象系統程序設計語言.面向對象編程被認為是代表下一步編程語言發展的主流.像強類型和繼承等面向對象 特征 據說可以減少開發時間,提高軟件重用率,并解決包括腳本語言技巧等其他問題.
面向對象編程實際能提供多少好處?不幸的是,我還沒有看到足夠的數據可以確切地回答這個問題.在我看來,對象只能提供一定的好處:或許能提高20-30%的創作力,但決不會有兩倍,更不用說是十倍.現在抱怨C++的和喜歡它的一樣多,并且一些語言專家開始公開反對面向對象編程.這一段剩下的部分用于解釋為什么對象不能像腳本一樣顯著地提高創作力,并討論腳本語言中可以獲得的面向對象編程的好處.
面向對象編程不能顯著提高創作力的原因是他沒有提高編程層次或鼓勵重用.像C++等面向對象語言中編程者仍然使用需要用大量細節來描述和操縱的基本的小單元工作.理論上可以開發強大的函數庫包,并且如果這些函數庫被廣泛使用就將提高編程層次.然而,這樣的函數庫卻很少.大多數面向對象語言的強類型使包的定義受限制從而難以重用.每個包都需要特殊類型的對象,如果兩個包在一起工作,就必須寫轉換代碼在兩個包需要的類型間進行翻譯.面向對象語言的另一個問題是他們強調繼承.當一個類借用為另一個類寫的代碼時執行繼承并不是一個好主意,它使軟件難以管理和重用.它把類的執行綁在一起,因而沒有另外一個類任何一個其它類都不可理解:不知道其繼承的方法在父類中如何執行,則無法理解子類;而不知道其方法如何被子類繼承,則無法理解父類.在一個復雜的類繼承中,不理解它所繼承的所有其他的類就無法理解任何一個類.更糟的是,一個類無法從它繼承的類中被分離以用于重用.多重繼承使這個問題變得更麻煩.執行繼承導致和goto語句被重復執行時所看到的一樣的交錯和不可靠.因此,面向對象系統經常不能處理復雜問題并缺少重用.
另一方面,腳本語言實際引起了有效的軟件重用.在有趣的組件由系統程序設計語言建立使他們使用了模塊,隨后用腳本語言把他們膠著在應用程序中.這種勞動的分割提供了為重用的自然的框架結構.組件被設計為可重用的組件和腳本間有定義好的接口以利于組件的使用.例如,在Tcl中組件是C中執行的常規命令.他們看起來更象是內在的命令,因而更容易在Tcl腳本中使用.在Visual Basic中組件是ActiveX的擴展,可用于從工具面板直接拖到窗體中.
不管怎么樣,面向對象編程至少提供了兩個有用的特性.第一個是封裝:對象用某種隱藏執行細節的方法把數據和代碼聯系起來.這使管理大型系統更加容易.另一個有用的特性是接口繼承,這涉及提供同樣方法的類和APIs,即使他們有不同的執行,這時類之間可以相互轉化,從而鼓勵重用.
幸運的是,對象的這些好處在腳本語言中可以像在系統程序設計語言中一樣實現,并且所有的腳本語言都提供面向對象編程.例如,Python是面向對象腳本語言,Python第五版包括提供對象,Object Rexx是Rexx的面向對象版本,而Incr Tcl是Tcl的面向對象版本.有一點不同是,腳本語言中的對象事物類型的,而系統程序設計語言中的對象是強類型的.
7.其他語言
這篇文章不是所有編程語言的全部特性記述.除了類型長度和編程層次以外還有許多編程語言的其他特性,并且還有許多不能被明確定義為系統程序設計語言或腳本語言的其他有趣的語言.例如,Lisp系統的語言就處于腳本語言和系統程序設計語言之間,兩方的特性它都有一些.它開創了像解釋和活動類型等現在在腳本語言中很普遍的觀點,又有自動存儲管理和綜合開發環境等在腳本和系統程序設計語言中同時使用的觀念.
8.結論
腳本語言代表一套與系統程序設計語言不同的協定.他們犧牲執行速度和與系統程序設計語言相關的類型長度而提供更高的編程創作力和軟件重用.當計算機變得更快和比編程者的勞動力更便宜時這個協定越來越行得通.在復雜的數據結構和算法中系統程序設計語言也適于創建組件,而腳本語言更適合在聯系復雜的應用程序中進行膠著.膠著工作變得越來越盛行,因而腳本在下個世紀將成為比今天更為重要的編程范例.
我希望這篇文章可以在三個方面影響編程群體;
★在開始一個新的項目并為每個工作選擇最強大的工具時我希望編程人員能考慮到腳本和系統編程的不同
★我希望組件框架的設計者能認識到腳本的重要性并確信框架不僅是創建組件的工具,同時也是把他們膠著在一起的工具
★我希望編程語言研究協會能轉變他們對腳本語言的態度,并在將來幫助發展更強大的腳本語言.對語言設計者而言,提高編程層次應該是唯一重要的目標,因為他是提高編程者創造力的最重要的因素;強類型是否有助于達到這個目標還不清楚.
9.答謝
這篇文章得益于很多人的觀點,包括Joel Bartlett, Bill Eldridge, Jeffrey Haemer, Mark Harrison, Paul McJones, David Patterson, Stephen Uhler, Hank Walker, Chris Wright,IEEE計算機執行官,和許多熱心參與這篇文章早期草稿網上新聞組討論的人.Colin Stevens 寫了MFC按鈕例子的版本,Strphen Uhler寫了Java版本.