Lispのどの方言を学ぶべきですか？[閉まっている]

Lispにはいくつかの異なる方言があることを私は知っています。Lispを学ぶことは新しい知的経験になると判断したので、どのLisp方言を学ぶべきか、そしてその理由を知りたいと思います。

他より人気のあるものはありますか？それらのいずれかが、より適切に文書化およびサポートされているように、より「完全」ですか？この方言の長所と短所は何ですか？

シンプルさと清潔さ、魅力的な機能、そして面白くて便利なソフトウェアを（自分自身に）書くことができ、学習ツールとして機能するプラットフォームのバランスを探したいと考えています。（この最後は、ずっと長く学習を続けます。）いくつかの可能性があります：

1. スキーム。おそらくすべての方言の中で最もきれいです。これが、The LittleSchemerがLISPからSchemeに翻訳された理由です。5番目のScheme標準仕様であるR5RSは、それ自体がすばらしい教育です。それは私が今まで読んだ中で最も素晴らしい言語とライブラリの仕様であり、合理的に包括的である最も短いものかもしれません。PLTスキーム（今ラケット）プラットフォームは、かなりまともなインタプリタとコンパイラが含まれるスクリプトのために良いです、また、学習のためのそれは素晴らしい作るいくつかの視覚的なツールを持っています。

2. CommonLisp。おそらく最もポータブルで包括的なバリアントであり、商用ソフトウェアなどを作成したい場合は、これがおそらく必要なものです。この標準は広範なライブラリを定義しており、それ以外にも多くのライブラリが利用可能です。CLOSがあり、おそらくどのOO言語よりもOOについて詳しく教えてくれます。また、一部のコンパイラは非常に優れています。欠点には、Schemeにはないいくつかの疣贅（関数を参照する変数用の個別の名前空間があるなど）、クリーンでシンプルではない（拡張機能が必要で妥協が必要なものの場合のように）などがあります。実世界の大規模なアプリケーションの場合）、衛生的なマクロがなく、Schemeよりも再帰を強調します。

3. Clojure。これはJVMで実行されるため、Java開発者にとってはすぐに役立つ可能性があります。いくつかの問題があります（たとえば、TCOがJVMに追加されると、これはいつか変わる可能性がありますが、末尾呼び出しの最適化を明示的に要求する必要があります）。マクロは、衛生的ではありませんが、変数のキャプチャを回避するのに役立ついくつかの機能を備えているため、CLよりも誤って実行するリスクを抑えながら、本当に必要な場合に変数をキャプチャできます。すべてのJavaライブラリに簡単にアクセスできます。これはおそらく「実世界」のコードにとっては良いことであり、学習の観点からはかなり無意味です。永続データ構造用のライブラリのセットとSTMのサポートがあり、同時の観点から非常に興味深いものになっています。これはおそらくあなたが 並行プログラミングと並列プログラミングを扱う新しい方法についてもっと学びたいと思っています。Clojureは、Javaと同じように大規模な本番アプリケーションで使用できるように見えます。つまり、本番アプリで行う「醜いこと」を実行したくない、実行しないという意味です。あなたが学んでいるとき。

4. EmacsLisp。LISPに関しては、これはそこにある良い例の1つではありません。その最大の欠点の1つは動的スコープですが、他にもたくさんあります。ただし、Emacsユーザーの場合、これはエディターの使用を改善するために学ぶことができる最も強力なツールである可能性があります。しかし、Emacsを拡張する方法を超えて、Emacs Lispを学ぶことから実際にどれだけ学ぶかは、私にとって未解決の質問です。EmacsLispで高階関数などの興味深い手法が実際にどのくらいの頻度で使用されているのかわかりません。

2018アップデート

私がこの投稿を書いてからほぼ10年が経ち、Lispファミリーの言語は現在、一般的なプログラマーの意識において大きな牽引力を獲得しているように見えます。これの多くは、それ自体でLispの適切に分離された方言になり、独自の優れたアイデアの多くを導入しただけでなく、JavaScriptをターゲットとするほぼ同一のバージョンを持ち、他の多くのLispに影響を与えたClojureに関連しているようです。他のプラットフォームをターゲットにします。たとえば、HyはCPython ASTとバイトコードをターゲットにしており、最初にPythonとの相互運用性を目指していますが、「疑わしい場合」はClojureのアイデアを使用しています。（最新のコミットからですが、後者は少し変更されている可能性があります。）

これが意思決定プロセスにもたらす大きな変化は、LispまたはLispに似た言語が利用可能であり、Perl、Ruby、Erlang、Go、さらにはすでに使用している言語またはプラットフォームと相互運用できることも確認する必要があることです。マイクロコントローラ上のC ++。

私はもっぱらためのスキーム、言うリトルスキーマーまだ私が今まで読んしようとした非常に硬い冊最も心blowingly楽しみの一つです。

SBCLでCommonLispをお勧めします。この組み合わせは、高速で強力、成熟しており、十分に文書化されています。

また、Clojureは最近、多くのマインドシェアを獲得していますが、これには正当な理由があります。優れたデータ構造、非常に優れた同時実行サポート（この点で、SchemeとCLは恥ずべきことです）、そして優れたコミュニティ。また、比較的単純で、CLは少なくともC ++と同じくらい複雑です。

これは、私がCLやSchemeを楽しんでいないということではありません。SICPでSchemeを学びました。そしてCLは私をClojureに連れて行った。それはすべて私が思うあなたの目標に依存します。非常に実用的なLispを学びたい場合は、Clojureを選択してください。それ以外の場合、CLまたはSchemeはどちらも優れています。

私はオブジェクト指向プログラミングが好きで、CLOSが最も優れたオブジェクトシステムであるため、CLを好みます。

私は学校でSchemeを学びました。それは素晴らしい学習体験であり、関数型プログラミングの基礎を決して忘れません。その有用性の核心であるステートレスラムダ計算を理解している限り、どのバージョンのLISPを選択するかはおそらく問題ではありません。

これは、MITがプログラミング入門コースでSchemeからPythonに切り替えた理由に関する興味深い記事です。

少なくとも最初は、それらすべてを言うでしょう。最終的には、SchemeまたはCommon Lispの設定を開発する可能性がありますが、どちらにも十分な違いがあるため、そこにあるすべてのものを処理するのが最善です。

たとえば、Schemeには継続があり、Common Lispで実装できますが、Schemeでそれらについて学ぶことは良いことです。

字句スコープと動的スコープの違いを学ぶことは重要であり、Common Lispとelispの両方を学ぶと、両方の意味に出くわすでしょう。

LFE（Lisp Flavoured Erlang）がいいでしょう。ErlangVMの上にlisp構文を置くことができます。

そもそも一種の「質問の誤謬」でしたが、OPはおそらくそれについて知りませんでした。一般的に、CommonとSchemeのlispersは、PCとAppleコンピュータの「人」のようなものであり、混ざり合うことはありません。どちらが最適かは、どちらが「機能する」かほど関連性がない可能性があります。本当に、それほど違いはありません。どちらを最初に学ぶかによって、どちらか一方が優先される可能性があります。（私にとって、空のリストは「何もない」はずで、CLではNILと呼ばれ、それが私をCommon Lisperにします。）EMACSを使用したSBCLとSlimeの統合は好きですが、SBCLは万人向けではありません。一つには、SBCLは非常に厳格です。「楽しみたい」だけなら、GNU clispは簡単で、事実上すべてのプラットフォームで利用できます。