現在流行一種語言叫做Clojure，他是lisp直接嫁接到java的結果，但是我就感覺這卻成為lisp的失敗。

因為lisp最強大最有優勢的能力是構造抽象，構造設計思想，而不是執行期以確定的方式執行，硬要拿去真正在一個環境中去執行，那麼它將被限制在一個環境，而是他的應用範圍變窄，比如我想開發作業系統或者開發分散式應用，或者為並行處理器GPU寫程式，那就無望了。

更悲劇的是Clojure與JAVA之間的關係是API呼叫關係，這將很大程度上限制lisp的高階抽象的發揮，我們不得不經常設計合適的謂詞為lisp與java之間找到一個合適的分界點。現實與天堂模糊的分界點是lisp能高效快速開發抽象邏輯的重要保障，如果加入一個分界點區分設計工作，那將是很複雜的，甚至是不能成功的，lisp的分界點轉換可能是很快的，人為跟不上的。

當然Common Lisp本身平臺也很弱小，弱小到根本不具備強大的目標平臺開發能力，我們活在人間，天堂的餅子再美好也無法餵飽我們的肚子。

我覺著Common Lisp要能有發展，最好的出路是借鑑類似UML的程式碼設計工具，做不同語言的程式碼生成器，因為所有平臺其都有最好的開發語言，並且有最好的廠商支援，這樣我們只需要能構造建立在format之上的高階抽象就可以讓lisp將進入任何平臺領域，成為最好的"設計語言".

比如我們要寫一個作業系統，並且這個作業系統很特別，他需要為AMD的GCN異構計算做全面優化，那麼這個作業系統肯定不能用已有的C語言去寫，因為以前的作業系統用C開發幾十年，架構穩定，雖然能移植過去，但是卻不能發揮性能，因為效能的關鍵取決於應用，這也是windows linux的失敗，那麼如果有更高階抽象作業系統 (lisp)那麼移植到GCN應該是容易的，抽象的作業系統，抽象的應用執行，將很容易為異構硬體平臺作優化。

又比如我們要寫一個分散式系統，有很多異構伺服器組成，有的是http,有的是c為目標平臺優化寫的主控伺服器，那麼要設計這種系統，如果能用lisp做設計，為不同平臺生成目的碼，那麼我們將可以站在全域性更上層的抽象上做更多全域性控制甚至更改推翻重來，用c寫的就玩不起了。