動態語言是為編寫KB級專案而設計的，從技術上講非常過時。絕大多數動態語言，都誕生在windows95之前。
那個年代的計算機使用軟盤儲存資料，最大容量才1.4MB，程式都特別簡單，一個作業系統才幾百kb。由於動態語言的語法簡潔，不僅節省空間，而且利於初學者學習，因此在那個儲存空間非常緊張，計算機還十分“腦殘”的年代，很有優勢。
但從windows95誕生，計算機全面進入圖形化時代，程式開始變得越來越龐大，商業軟體從平均幾KB，增大到幾MB，幾十MB，甚至幾百MB。
從此，動態語言越來越難以編寫出合格的程式，靜態語言才開始逐漸流行起來，逐漸取代了動態語言的統治地位。
動態語言和靜態語言最大的區別，在於可維護性的不同。
小學生剛剛學習寫作文的時候，總有很多字不會寫。有的老師會讓學生，把不會寫的字，畫成一個圈兒，即O。
一個句子，原本應該寫成寫成“今天下雨了”。而有些小學生不會寫“雨”字。就可以寫成“今天下O了”。這個“O”可以代表任何東西，當然也可以代表雨。
對於判作業的老師來說，這個“O”就是動態的。直到老師猜出這個“O”是雨之後，才能確定這個句子是不是病句。
這種畫圈兒的規則，是一把雙刃劍，整體講是弊大於利的。好處是它可以讓學生只掌握很少的漢字，就能寫出作文。但缺點是圈兒一旦變多，就會失控。常常連作者自己都分不清，每個圈兒分別代表啥？
可是對於高年級的學生，就不允許使用“O”了。遇到不會寫的字，就要去查字典，只有寫出所有的字，才能把作文寫完。對於判作業的老師來說，這就是靜態的，這個句子是不是病句，一眼就能看出來。
程式語言比我們的例子要複雜，但道理是一樣的，區別就是它不能只畫“O”，而是不同的東西，需要用不同的“名字”表示，為了便於說明，下面的“名字”都使用一個字母來命名。
比如一個句子是“板凳寬，扁擔長，板凳不讓扁擔綁在板凳上”。
用動態語言表示，則寫成“A寬，B長，A不讓B綁在A上”。
寫起來很省事，但維護起來就費勁了。因為A和B可以代表任何東西，憑什麼一定就是“板凳寬，扁擔長”，而不是“肥皂寬，牙刷長”？
而用靜態語言表示，則是“板凳A寬，扁擔B長，A不讓B綁在A上”。
透過對比發現，靜態語言比動態語言，多了一開始的“板凳”和“扁擔”這兩個詞語。相當於從一開始，就標明瞭A是板凳，B是扁擔。
只要用腦子記住“A是板凳，B是扁擔”，豈不就能達到同樣的效果？僅僅一個句子當然是可以的，人人都能記得住。而商業程式的程式碼量，一般平均在十萬行左右。你不僅需要記住什麼代表板凳和扁擔，你還得記住水桶，暖壺，掃帚，簸萁，鍋，碗，瓢，盆，油，鹽，醬，醋，煙，酒，茶，糖。。。
所以，為了解決這個問題，動態語言就需要靠加註釋，來彌補自身可維護性的不足。可這樣做也是不靠譜的。因為如果對程式碼進行封裝，所需要註釋的文字量，就會超過程式碼量本身，到時候你根本不是“寫程式碼加註釋”，而是“寫註釋加程式碼”。
總之，動態語言只適合寫非常非常小的程式，中型以上的程式，通常要使用靜態語言編寫，才會比較容易維護。我個人只在編寫1000行以內的小工具時，才會使用動態語言，如Python、Lua等。但即便如此，也還是多次陷入過“第二天看不懂”的困境。
當然“不適合”不代表“不能”，就像“徒手搬磚只適用於小型建築，大中型建築要使用工程機械”，這說法我一般認為是正確的。但總有一些人會舉極端的例子來反駁，說萬里長城和金字塔是用手磊出來的，這就實在沒意思了。。。。
動態語言存在的的第二個問題，就是很難發現錯誤。
假如我們遇到一個遊戲，它是用靜態語言編寫的，其中有一段程式碼是這樣的(虛擬碼):
角色 A=李逍遙；
怪物 B=樹妖;
技能 C=御劍術;
武器 D=鋼劍;
然後我們編寫了一段程式碼:“A裝備著D，發動了C，擊敗了B”
這段程式碼很容易翻譯，就是“李逍遙裝備著鋼劍，發動了御劍術，擊敗了樹妖”。
假如我們一時不小心，把程式碼寫成“李逍遙裝備著樹妖，發動了鋼劍，擊敗了御劍術”的話，會怎麼樣？
這時候IDE會立刻報錯，並提示你出現了三個錯誤。
1，樹妖是怪物，不能裝備
2，鋼劍是武器，不能當做技能使用
3，御劍術是技能，無法被擊敗
如果不排除這些錯誤，你的程式就無法繼續順利編寫下去。所以你只好先排除這三個問題之後，才能繼續寫程式碼，套用前面的例子，也就是高年級學生“查字典”了。
由於絕大多數的問題，都必須在寫程式碼的過程中，透過“查字典”排除掉，所以只要你的程式可以順利寫完，執行起來也基本不會有太大的問題了。
但如果這個程式是使用動態語言編寫的，則不會報錯。因為B可以是任何東西，它可以是鋼劍，也可以是樹妖。直到你的程式寫完，無數BUG一下子冒出來，IDE卻依然顯示“一切正常”。
所以使用動態語言，你就要在每一個可能疏忽的地方，加上註釋，提醒自己A是啥東西，B又是啥東西。。。。。最後你會發現，若要保證你自己寫的程式不出BUG，而且日後還可以正常維護的話，那麼你需要寫的註釋，遠比程式碼本身還要多。
動態語言是為編寫KB級專案而設計的，從技術上講非常過時。絕大多數動態語言，都誕生在windows95之前。
那個年代的計算機使用軟盤儲存資料，最大容量才1.4MB，程式都特別簡單，一個作業系統才幾百kb。由於動態語言的語法簡潔，不僅節省空間，而且利於初學者學習，因此在那個儲存空間非常緊張，計算機還十分“腦殘”的年代，很有優勢。
但從windows95誕生，計算機全面進入圖形化時代，程式開始變得越來越龐大，商業軟體從平均幾KB，增大到幾MB，幾十MB，甚至幾百MB。
從此，動態語言越來越難以編寫出合格的程式，靜態語言才開始逐漸流行起來，逐漸取代了動態語言的統治地位。
動態語言和靜態語言最大的區別，在於可維護性的不同。
小學生剛剛學習寫作文的時候，總有很多字不會寫。有的老師會讓學生，把不會寫的字，畫成一個圈兒，即O。
一個句子，原本應該寫成寫成“今天下雨了”。而有些小學生不會寫“雨”字。就可以寫成“今天下O了”。這個“O”可以代表任何東西，當然也可以代表雨。
對於判作業的老師來說，這個“O”就是動態的。直到老師猜出這個“O”是雨之後，才能確定這個句子是不是病句。
這種畫圈兒的規則，是一把雙刃劍，整體講是弊大於利的。好處是它可以讓學生只掌握很少的漢字，就能寫出作文。但缺點是圈兒一旦變多，就會失控。常常連作者自己都分不清，每個圈兒分別代表啥？
可是對於高年級的學生，就不允許使用“O”了。遇到不會寫的字，就要去查字典，只有寫出所有的字，才能把作文寫完。對於判作業的老師來說，這就是靜態的，這個句子是不是病句，一眼就能看出來。
程式語言比我們的例子要複雜，但道理是一樣的，區別就是它不能只畫“O”，而是不同的東西，需要用不同的“名字”表示，為了便於說明，下面的“名字”都使用一個字母來命名。
比如一個句子是“板凳寬，扁擔長，板凳不讓扁擔綁在板凳上”。
用動態語言表示，則寫成“A寬，B長，A不讓B綁在A上”。
寫起來很省事，但維護起來就費勁了。因為A和B可以代表任何東西，憑什麼一定就是“板凳寬，扁擔長”，而不是“肥皂寬，牙刷長”？
而用靜態語言表示，則是“板凳A寬，扁擔B長，A不讓B綁在A上”。
透過對比發現，靜態語言比動態語言，多了一開始的“板凳”和“扁擔”這兩個詞語。相當於從一開始，就標明瞭A是板凳，B是扁擔。
只要用腦子記住“A是板凳，B是扁擔”，豈不就能達到同樣的效果？僅僅一個句子當然是可以的，人人都能記得住。而商業程式的程式碼量，一般平均在十萬行左右。你不僅需要記住什麼代表板凳和扁擔，你還得記住水桶，暖壺，掃帚，簸萁，鍋，碗，瓢，盆，油，鹽，醬，醋，煙，酒，茶，糖。。。
所以，為了解決這個問題，動態語言就需要靠加註釋，來彌補自身可維護性的不足。可這樣做也是不靠譜的。因為如果對程式碼進行封裝，所需要註釋的文字量，就會超過程式碼量本身，到時候你根本不是“寫程式碼加註釋”，而是“寫註釋加程式碼”。
總之，動態語言只適合寫非常非常小的程式，中型以上的程式，通常要使用靜態語言編寫，才會比較容易維護。我個人只在編寫1000行以內的小工具時，才會使用動態語言，如Python、Lua等。但即便如此，也還是多次陷入過“第二天看不懂”的困境。
當然“不適合”不代表“不能”，就像“徒手搬磚只適用於小型建築，大中型建築要使用工程機械”，這說法我一般認為是正確的。但總有一些人會舉極端的例子來反駁，說萬里長城和金字塔是用手磊出來的，這就實在沒意思了。。。。
動態語言存在的的第二個問題，就是很難發現錯誤。
假如我們遇到一個遊戲，它是用靜態語言編寫的，其中有一段程式碼是這樣的(虛擬碼):
角色 A=李逍遙；
怪物 B=樹妖;
技能 C=御劍術;
武器 D=鋼劍;
然後我們編寫了一段程式碼:“A裝備著D，發動了C，擊敗了B”
這段程式碼很容易翻譯，就是“李逍遙裝備著鋼劍，發動了御劍術，擊敗了樹妖”。
假如我們一時不小心，把程式碼寫成“李逍遙裝備著樹妖，發動了鋼劍，擊敗了御劍術”的話，會怎麼樣？
這時候IDE會立刻報錯，並提示你出現了三個錯誤。
1，樹妖是怪物，不能裝備
2，鋼劍是武器，不能當做技能使用
3，御劍術是技能，無法被擊敗
如果不排除這些錯誤，你的程式就無法繼續順利編寫下去。所以你只好先排除這三個問題之後，才能繼續寫程式碼，套用前面的例子，也就是高年級學生“查字典”了。
由於絕大多數的問題，都必須在寫程式碼的過程中，透過“查字典”排除掉，所以只要你的程式可以順利寫完，執行起來也基本不會有太大的問題了。
但如果這個程式是使用動態語言編寫的，則不會報錯。因為B可以是任何東西，它可以是鋼劍，也可以是樹妖。直到你的程式寫完，無數BUG一下子冒出來，IDE卻依然顯示“一切正常”。
所以使用動態語言，你就要在每一個可能疏忽的地方，加上註釋，提醒自己A是啥東西，B又是啥東西。。。。。最後你會發現，若要保證你自己寫的程式不出BUG，而且日後還可以正常維護的話，那麼你需要寫的註釋，遠比程式碼本身還要多。