問題是，在現實世界中同質性的價值有多大？
可能相當重要：看看所有做服務器端Javascript的人。 Javascript在任何情況下都不是最高級的，它對服務器端代碼的庫支持並不是那麼好，但是使用它有很大的收穫。
每當出現任何錯誤，你必須加載在Firebug的頁面時，
取決於什麼「東西」是。我實際上還記得上一次我不得不打開Firebug來看看發生了什麼問題 - 我確實經歷過這個階段，但也有很多次不是這樣。例如，如果你從s-exps生成你的CSS，那麼你的CSS的問題可能只會讓你需要查看「編譯」CSS怪異的語法問題（如IE6技巧）。如果你只是看看頁面，並決定你需要一個額外的邊框，那麼你可以添加(:border 1)並完成它。 （當然，如果你處理這些來生成一整套CSS規則來服務於客戶端，那麼這是一個更大的勝利。）
另一種思考方式：在極少數情況下，我需要在現代Web應用程序上工作時，請拔出數據包嗅探器和反彙編器。是的，這很糟糕，但是有了好的圖書館，這也是非常罕見的。我不想整天寫低級代碼，只是爲了避免在需要這種級別的信息的情況下，在極少數情況下切換到數據包嗅探器的阻抗不匹配。
這假定你想達到你寫作（V）HLL代碼的水平。Common Lisp無法在C語言中擊敗C語言，如果你只是試圖在HTML中吐出一個簡單的博客，那麼你就不在那裏了：Rails真的很擅長這種事情。但是有大量的實驗性編程能夠改變一個標誌並在客戶端運行代碼，而不是服務器是有用的。
，然後你會看生成的HTML，CSS和Javascript，而不是Lisp的來源，所以你必須保持你的頭的映射。 Lisp提供的同質性是否真的能解決任何問題，或僅僅是解決問題的壁紙，最終會再次向下遊彈出？
我已經寫全Lisp和所有JavaScript的Web應用程序，我認爲最好的答案我現在可以給的是：它可以。我使用過Parenscript，主要的問題是Parenscript是一種Lisp-y語言，但它不是Common Lisp，也不是可以在服務器端使用的任何其他完整語言。 （如果有一個用於Javascript編譯器的Common Lisp，就像GWT是用於Java的，那麼它會很棒，但我沒有看到任何人認真地嘗試製作一個。）所以，如你所見，兩種語言。
JavaScript是一個好一點的今天，在這方面，因爲你可以準確地運行在兩地相同的代碼。這不是相當理想的，因爲你的服務器端JavaScript可能有，你不能保證會存在於客戶端功能（除非你限制你的用戶，比方說，火狐的最新版本）。如果你像我一樣，你不想限制你的服務器代碼到每個瀏覽器中運行的JS，所以你的服務器端JS和客戶端JS將會是微妙的不同。這不是一個破壞者 - 它仍然很不錯 - 但它仍然是兩種略有不同的語言。
我認爲這將是很酷的，如果有，可以採取寫在最新的Javascript（1.8.5）的代碼，並生成老派的Javascript在任何瀏覽器中運行的程序。我不認爲這樣的計劃存在，但我不知道它會有多困難。
有計劃的實現Javascript的，所以可能與計劃情況較好。我應該仔細研究一下這些日子。
不必使用服務器端語言，是從我的客戶端語言（JavaScript）的完全不一樣，當我屢屢受挫。但是當我不得不使用低於Lisp的語言（大多數語言）時，我也感到沮喪。像Lisp一樣，還是更像Javascript是更大的勝利？我不知道。我希望我不必選擇。
來源
2011-04-04 19:57:09
Ken