編譯型語言
編譯型語言和匯編語言一樣，有一個負責翻譯的程序來對我們編寫的源代碼進行轉換，生成相對應的可執行代碼。這個過程說得專業一點，就稱為編譯（Compile），而負責編譯的程序自然就稱為編譯器（Compiler）。
如果我們寫的程序代碼都包含在一個源文件中，那么通常編譯之后就會直接生成一個可指定文件，我們就可以直接運行了。但是對於一個比較復雜的項目，我們為了方便管理，通常會把代碼分散在各個源文件中，作為不同的模塊來組織。這時編譯各個文件時就會生成目標文件（Object File）而不是前面說的可執行文件。
一般一個源文件的編譯都會對應一個目標文件，這些目標文件里面的內容基本上已經是可執行代碼了，但由於只是整個項目的一部分，所以我們還不能直接運行。等到所有的源文件都編譯完成，我們就可以最后把這些半成品的目標文件打包成一個可執行文件了。這個工作由另一個程序負責完成，由於這個過程是把包含可執行代碼的目標文件連接裝配起來，所以又稱為鏈接（Link），而負責鏈接的程序自然就稱為鏈接程序（Linker）了。
鏈接程序除了鏈接目標文件外，可能還要管理各種資源，像圖標文件、聲音文件什么的，又要負責去除目標文件之間的冗余重復代碼等等，其實鏈接程序也很不容易呢。但是鏈接完成之后，一般就可以得到我們想要的可執行文件了。
解釋型語言
從字面上看，編譯和解釋都有翻譯的意思，他們的區別就在於翻譯的時機安排不太一樣。
打個比方，假如你打算閱讀一本外文書，而你不知道這門外語，那么你可以找一名翻譯，給他足夠的時間讓他從頭到尾把整本書翻譯好，然后把書的母語版交給你閱讀。或者你也可以立刻讓這名翻譯輔助你閱讀，讓他一句一句地給你翻譯，如果你像往回看某個章節，他也得給你重新翻譯。這兩種翻譯的方式，前者就相當於編譯型語言，后者就相當於解釋型語言。
編譯型語言就是一次性把所有的代碼轉換成機器語言，然后寫成可執行文件。
解釋性語言則是在程序運行的前一刻還只有源代碼沒有可執行文件，程序每執行到源代碼的某一條指令，就會有一個稱為解釋程序的外殼程序將源代碼轉換成二進制代碼以供執行，也就是說，要不斷地解釋、執行、解釋、執行、解釋、執行。。。像極了人生。因此，解釋型語言是離不開解釋程序的。像早期的BASIC就是一門經典的解釋性語言，要執行BASIC程序，就要進入BASIC環境，然后才能加載程序源文件和運行。
編譯型語言和解釋型語言的比較
因為解釋型語言編寫的程序總是以源代碼的形式出現，因此只要有相對應的解釋器的話，移植幾乎不成問題。編譯型語言編寫的程序雖然源代碼可以移植，但前提是必須針對不同的環境分別進行編譯，對於復雜的工程來說，的確是一個不小的時間消耗，更何況可能有些細節的地方還是要修改源代碼。
而且，解釋型語言因為省卻了編譯的步驟，修改調試會十分方便，編輯完畢之后即可立即運行，不必像編譯型語言一樣每次小小改動都要耐性等待漫長的Compling。。。Linking。。。這樣的編譯鏈接過程。不過凡事有利有弊，由於解釋型語言是將編譯的過程放到執行過程種，這就決定了解釋型語言注定要比編譯型語言慢上一大截，像幾百倍的速度差距也是不足為奇的。
編譯型語言和解釋型語言各有各的優點和缺點。前者由於程序執行速度快，同等條件下對系統要求較低，因此開發操作系統、大型應用程序、數據庫系統等時都會采用它，像C/C++、Pascal/Object Pascal（Delphi）、VB等語言基本都可視作編譯型語言。而一些網頁腳本、服務器腳本和輔助開發接口這樣，對速度要求不高，對不同系統平台間的兼容性有一定要求的程序則通常使用解釋型語言，像Java（好好想想為什么，嘿嘿）、JavaScript、VBScript、Perl和Python等就是解釋型語言。
因為編譯型語言和解釋型語言各有優缺點又相互對立，因此很多新興語言都有把兩者折衷結合起來的趨勢。例如Java語言雖然比較接近解釋型語言的特征（要依賴JVM虛擬機運行），但在執行之前已經預先進行過一次預編譯，生成的代碼是介於機器碼和Java源代碼之間的中介代碼，運行時由JVM(Java的虛擬機平台，可視為解釋器）解釋執行。它既保留了源代碼的高抽象、可移植的特點，又已經完成了對源代碼的大部分預編譯工作，所以執行起來比純種解釋型語言要快很多。
隨着設計技術和硬件的不斷發展，編譯型語言和解釋型語言的界限正在不斷變得模糊。
總結
編譯型語言：執行速度快、效率高、依靠編譯器、跨平台性較差。
解釋型語言：執行速度慢、效率低、依靠解釋器、跨平台性能好。
"暴雨天，我至少想講掛念你。"