注意：我不是問哪個要學，哪個更好，或者類似的東西。Scheme和Common Lisp之間的實際區別是什麼？ （或Lisp的任何其他兩種方言）
我拿起SICP的免費版本，因爲我覺得它會很好閱讀（我聽說過很好的東西，我對這種編程方面很感興趣）。
我知道Scheme是Lisp的一種方言，我想知道：Scheme和Common Lisp之間的實際區別是什麼？
似乎有很多關於'CL有一個更大的stdlib ... Scheme對現實世界的編程不是很好'，但沒有真正的事情說'這是因爲CL是這個/有這個'。
這是一個棘手的問題，因爲差異既是技術性的（更重要的是在我看來）的文化差異。答案只能提供一個不精確的主觀觀點。這是我要在這裏提供的。有關原始技術細節，請參見Scheme Wiki。
計劃是一種建立在提供優雅，一致，深思熟慮的基礎語言基礎上的語言，可以構建實用和學術應用語言。
很少，你會發現有人在寫純R5RS（或R6RS）方案的應用，因爲簡約的標準，大部分代碼是不能跨越計劃實現便攜。這意味着如果你想編寫某種最終用戶應用程序，你將必須仔細選擇你的Scheme實現，因爲這個選擇很大程度上決定了你可以使用哪些庫。另一方面，設計實際應用程序語言的相對自由意味着Scheme實現經常提供其他地方聞所未聞的功能;例如，PLT Racket使您能夠使用靜態打字並提供一種非常適合語言的IDE。
互操作性超越了基本語言是通過社區推動SRFI過程中提供，但任何給定的SRFI的可用性因實施而異。
大多數方案方言和庫專注於函數式編程習語，如遞歸而不是迭代。當你想做OOP時，你可以加載各種對象系統作爲庫，但是與現有代碼的集成很大程度上取決於Scheme方言及其周圍的文化（例如，Chicken Scheme似乎比Racket更面向對象）。
交互式編程是計劃子社區英寸MIT方案不同的是著名的強interactivitiy支持，而PLT球拍感覺更靜態的另一點。在任何情況下，交互式編程似乎都不是大多數Scheme子小組的主要關注點，我還沒有看到與大多數Common Lisp具有類似交互性的編程環境。
Common Lisp的是一個戰鬥磨損的語言設計的實際編程。它充滿了醜陋的疣和兼容性黑客 - 與Scheme的優雅極簡主義完全相反。但它本身也更有特色。
Common Lisp育出了一個相對較大的可移植庫生態系統。即使在部署應用程序之後，您通常可以隨時切換實現，而不會有太多麻煩。總體而言，Common Lisp比Scheme更統一，如果完成的話，更激進的語言實驗通常嵌入爲便攜式庫，而不是定義全新的語言方言。正因爲如此，語言擴展往往更保守，但也更加可組合（並且通常是可選的）。
普遍有用的語言擴展，像外國的功能接口，不通過正式途徑發展，但依靠在所有主要的Common Lisp的實現提供準標準庫。
語言成語的函數式，命令，和麪向對象的方法野生混合物，並且通常，Common Lisp中感覺更像命令式語言不是一個功能之一。它也非常具有動態性，可以說比任何流行的動態腳本語言（例如，類重新定義適用於現有的實例，並且條件處理系統具有正確的交互性）更可靠，並且交互式探索性編程是「Common Lisp方式」。這也體現在Common Lisp可用的編程環境中，實際上所有這些環境都提供了與正在運行的Lisp編譯器的某種直接交互。
Common Lisp具有內置對象系統（CLOS），這是一種比單純的異常處理，運行時可分性以及各種內置數據結構和實用程序（包括臭名昭着的LOOP宏，迭代子語言對於Scheme來說太難看了，但是太不用說了，太有用了，以及格式化字符串中帶有格式化機制的GOTO支持）。
由於基於圖像的交互式開發，並且由於較大的語言，Lisp實現通常在操作系統上的可移植性低於Scheme實現。例如，讓一個Common Lisp在嵌入式設備上運行並不是一件容易的事情。與Java虛擬機類似，您在虛擬內存受限的計算機上也會遇到問題（如基於OpenVZ的虛擬服務器）。另一方面，Scheme實現往往更加緊湊和便攜。 ECL實施的質量越來越高，這一點有所緩解，儘管其本質仍然如此。
如果您關心商業支持，有幾家公司提供自己的Common Lisp實現，包括圖形化GUI構建器，專用數據庫系統等等。
總結，Scheme是一種更優雅的設計語言。它主要是一種具有一些動態特徵的功能性語言。它的實現代表了具有不同特徵的各種不兼容的方言。 Common Lisp是一個完備的，高度動態的多範式語言，具有各種醜陋但實用的特性，它們的實現在很大程度上相互兼容。方案方言傾向於比Common Lisp更靜態且交互性更低; Common Lisp實現往往比較笨重且難以安裝。
無論你選擇哪種語言，我都希望你有很多樂趣！ :)
'你應該寫一些最終用戶應用程序'+1 – kmoe 2014-08-22 17:49:01
方案：
共同口齒不清：
是一些點，肯定有更多的人，我不記得現在。
您可以參考「RSR7」;這應該是「R6RS」。編輯爲R7RS的 – 2011-03-20 18:41:47
。我有新的計劃標準 – Moe 2011-03-20 19:09:33
這是一個公平回答的難題，特別是因爲許多LISP人員會將Scheme劃分爲LISP。
喬希布洛赫（這種類比可能不是他的發明）描述選擇一種語言就像選擇一個當地的酒吧。那麼：
「計劃」酒吧裏有很多編程語言的研究人員。這些人對語言的含義，保持清晰和簡單以及討論創新的新功能時都非常關注。每個人都有自己的語言版本，旨在讓他們探索他們自己的編程語言特定角落。該計劃的人員非常喜歡他們從LISP那裏獲得的括號化語法;它的靈活性和輕便性以及統一性，並且消除了很多語言擴展的障礙。
「LISP」酒吧？那麼......我不應該評論;我沒有花足夠的時間在那裏:)。
一些基本的實際差別：
(function ...)值，並明確調用使用(funcall ...)nil（空單）被認爲是假的（例如，在if） ，並且是唯一的虛假價值。在方案中，空列表被認爲是真實的，（獨特）#f是唯一的錯誤值
「計劃是不利於真實世界的編程」 ......我在做方案的現實世界編程（好吧，不多）。 – knivil 2011-03-20 14:26:09
不知道這是否是潛臺詞，但我會建議在計劃中進行SICP練習。幾乎所有的實現都可以使用正確的參數，因爲它們關注的子集非常小。您只需要爲您的選擇找到合適的參數，例如，在Racket中，它可能是R5RS模式。來自SICP的許多想法將幫助您進一步學習Lisp，即使您繼續使用Common Lisp或Clojure也是如此。 – spacemanaki 2011-03-20 14:42:11
最後我看到，Scheme規範大約有50頁，CL規範超過了1000個。因此，只要將CL規範打開到任何頁面，那麼很可能CL就是這樣，但不是Scheme。 :-) – Ken 2011-03-20 15:06:50