什么是「動(dòng)態(tài)語(yǔ)言」？這個(gè)概念其實(shí)沒(méi)有一個(gè)明確的定義。基本上它是一個(gè)程度的度量。這個(gè)程度就是該語(yǔ)言的 runtime 到底使用多少 bookkeeping 數(shù)據(jù)。

　　讀過(guò)《Design and Evolution of C++》的人一定知道 C++ 這個(gè)變態(tài)的 zero-bookkeeping 原則。任何 C++ 語(yǔ)言的高層概念，其實(shí)都已經(jīng)在編譯階段被剝離掉了。從最后的目標(biāo)代碼中你很難再看出這是一種高級(jí)語(yǔ)言。當(dāng)然，其代價(jià)就是程序員必須理解為什么 C++ 不能實(shí)現(xiàn)某些功能。而且必須從機(jī)器的角度去理解。

　　動(dòng)態(tài)語(yǔ)言其實(shí)就是一個(gè)不斷添加 bookkeeping 的過(guò)程。

　　比如說(shuō)，C++ 中為了實(shí)現(xiàn)多態(tài)還是不得不有一個(gè)中間機(jī)制，這就是虛表。但是你很難說(shuō)虛表就是一個(gè) bookkeeping 結(jié)構(gòu)。因?yàn)樗?jiǎn)單了。而 Objective-C 就大大增加了對(duì)成員函數(shù)調(diào)用的 bookkeeping 機(jī)制。因?yàn)槿绱耍?Objective-C 對(duì) action-message 的實(shí)現(xiàn)就簡(jiǎn)單多了，因?yàn)槟憧梢耘袛嘁粋€(gè)成員函數(shù)是否存在。而且也可以在不確定對(duì)象類(lèi)型的情況下，指定一個(gè)方法作為回調(diào)函數(shù)。

　　C++ 的另一個(gè)問(wèn)題，內(nèi)存管理，根本原因在于其對(duì)象引用采用 raw pointer 機(jī)制。Objective-C 并沒(méi)有改善這一點(diǎn)。但是也并非全無(wú)改善，在 Objective-C 里，一個(gè) pointer 幾乎永遠(yuǎn)必須指向 NSObject，而這個(gè)東西是有引用基數(shù)的。當(dāng)然，它并沒(méi)有完全解決 over-release 或者 use-after-release 的問(wèn)題。到了 Java，Python，Lua 這樣的語(yǔ)言，raw pointer 就完全消失了。

　　而 C++ 的內(nèi)存管理，除了 heap 就只有一個(gè)借助 CPU stack 管理的棧。在動(dòng)態(tài)語(yǔ)言里，就要考慮 lexical scope 的表現(xiàn)，這就需要更多的 bookkeeping。這點(diǎn) Objective-C 也并沒(méi)有實(shí)現(xiàn)。

　　語(yǔ)法的處理，在 C++ 中是完全在 runtime 之前進(jìn)行。而在 Python，Lisp，Lua 這樣的語(yǔ)言中是有 eval 這樣的機(jī)制存在的。

　　所以，Objective-C 是比 C 和 C++ 擁有更多動(dòng)態(tài)特性，而比 Lua，Lisp 缺乏一些動(dòng)態(tài)特性的語(yǔ)言。至于題目中進(jìn)行比較的 Python，也只能說(shuō)是個(gè)更少缺乏動(dòng)態(tài)特性的語(yǔ)言。Python 缺乏 lexical scope，也缺乏對(duì) continuation 的支持。它的 stack 借助 CPU stack（當(dāng)然有一個(gè) stackless-Python，不過(guò)非官方），相比之下，Lua 為了支持 coroutine，Lisp 為了 full-continuation，都是自行維護(hù) VM stack 的。Python 的 bookkeeping 與 Lua 和 Lisp 比起來(lái)也是不夠的。

　　1.動(dòng)態(tài)類(lèi)型：

　　即運(yùn)行時(shí)再?zèng)Q定對(duì)象的類(lèi)型。簡(jiǎn)單說(shuō)就是id類(lèi)型，任何對(duì)象都可以被id指針?biāo)福挥性谶\(yùn)行時(shí) 才能決定是什么類(lèi)型。像內(nèi)置的明確的基本類(lèi)型都屬于靜態(tài)類(lèi)型（int、NSString等）。靜態(tài)類(lèi)型在編 譯的時(shí)候就能被識(shí)別出來(lái)。所以，若程序發(fā)生了類(lèi)型不對(duì)應(yīng)，編譯器就會(huì)發(fā)出警告。而動(dòng)態(tài)類(lèi)型就編譯器編譯的時(shí)候是不能被識(shí)別的，要等到運(yùn)行時(shí)（run time），即程序運(yùn)行的時(shí)候才會(huì)根據(jù)語(yǔ)境來(lái)識(shí)別。所以這里面就有兩個(gè)概念要分清：編譯時(shí)跟運(yùn)行時(shí)。

　　2.動(dòng)態(tài)綁定：

　　基于動(dòng)態(tài)類(lèi)型，在某個(gè)實(shí)例對(duì)象被確定后，其類(lèi)型便被確定了。該對(duì)象對(duì)應(yīng)的屬性和響應(yīng)的消息也被完全確定，這就是動(dòng)態(tài)綁定。比如我們一般向一個(gè)NSObject對(duì)象發(fā)送-respondsToSelector：或者 -instancesRespondToSelector：等來(lái)確定對(duì)象是否可以對(duì)某個(gè)SEL做出響應(yīng)，而在OC消息轉(zhuǎn)發(fā)機(jī)制被觸發(fā)之前，對(duì)應(yīng)的類(lèi) 的+resolveClassMethod：和+resolveInstanceMethod：將會(huì)被調(diào)用，在此時(shí)有機(jī)會(huì)動(dòng)態(tài)地向類(lèi)或者實(shí)例添加新的方 法，也即類(lèi)的實(shí)現(xiàn)是可以動(dòng)態(tài)綁定的；isKindOfClass也是一樣的道理。

　　3.動(dòng)態(tài)加載：

　　所謂動(dòng)態(tài)加載就是我們做開(kāi)發(fā)的時(shí)候icon圖片的時(shí)候在Retina設(shè)備上要多添加一個(gè)張@2x的圖片，當(dāng)設(shè)備更換的時(shí)候，圖片也會(huì)自動(dòng)的替換。

　　什么是 bookkeeping 信息：Bookkeeping 就是 source code 里的信息用 declarive 的方式來(lái)保留在目標(biāo)碼中。

　　這里舉一個(gè)所有語(yǔ)言都會(huì)舍棄的 bookkeeping 信息，就是 local variable name。Compiler 或者 interpreter 在遇到一個(gè) local variable 的時(shí)候，一定要給它分配一個(gè)寄存器或者 stack entry（其實(shí)寄存器也就是 stack entry 的一種，見(jiàn)我的 blog 《什么是寄存器》）。所以在 runtime 時(shí) variable name 就成了多余的。所以幾乎所有語(yǔ)言，不管是 native 還是 byte code，都會(huì)舍棄 local name。

　　再比如說(shuō) raw pointer，就是說(shuō)編譯之后的代碼里沒(méi)有一個(gè)固定的 field 來(lái)說(shuō)明一個(gè) value 到底是不是 pointer。一個(gè) value 是不是 pointer 完全靠引用它的代碼本身來(lái)解釋。當(dāng)然你去分析目標(biāo)碼本身可能會(huì)得出「這是一個(gè) pointer」的結(jié)論，但這是從 imperative code 中分析的來(lái)的，而不是從一個(gè) field 中得到的明確的 declartive 信息。