LISPコミュニティがそれほど断片化されているのはなぜですか？
まず、言語の2つの主要な方言（Common LISPとScheme）があるだけでなく、各方言には多くの個別の実装があります。たとえば、Chicken Scheme、Biglooなど...それぞれわずかな違いがあります。
最近の言語は決定的な実装/仕様を持っている傾向があるため、現代の観点からはこれは奇妙です。 Java、C＃、Python、Rubyなどを考えてみてください。それぞれに、APIドキュメントやダウンロードなどのためにアクセスできる単一の決定的なサイトがあります。もちろん、LISPはこれらすべての言語よりも前から存在しています。しかし、繰り返しになりますが、C/C++でさえ（多かれ少なかれ）標準化されています。
Lispの時代によるこのコミュニティの断片化はありますか？それとも、さまざまな実装/方言がさまざまな問題を解決することを目的としていますか？ LISPが単一の決定的な実装の周りで成長した言語ほど統一されない理由があることは理解していますが、現時点で、LISPコミュニティがこの方向に進むべきではない理由はありますか？
LISPコミュニティは断片化されていますが、他のすべても断片化されています。
なぜこれほど多くのLinuxディストリビューションがあるのですか？
なぜこれほど多くのBSDバリアントがあるのですか？ OpenBSD、NetBSD、FreeBSD、... MacOSXですら。
なぜこれほど多くのスクリプト言語があるのですか？ Ruby、Python、Rebol、TCL、PHP、その他数え切れないほど。
なぜこれほど多くのUnixシェルがあるのですか？ sh、csh、bash、ksh、...？
Logo（> 100）、Basic（> 100）、C（countless）、..の実装が非常に多いのはなぜですか。
Rubyのバリエーションがたくさんあるのはなぜですか？ Ruby MRI、JRuby、YARV、MacRuby、HotRuby？
Pythonにはメインサイトがあるかもしれませんが、いくつかのわずかに異なる実装があります：CPython、IronPython、Jython、Python for S60、PyPy、Unladen Swallow、CL-Python、...
C（Clang、GCC、MSVC、Turbo C、Watcom C、...）、C++、C＃、Cilk、Objective-C、D、BCPL、...があるのはなぜですか？
それらのいくつかを50にして、そのときの方言と実装の数を確認してください。
LISPは多様だと思います。なぜなら、すべての言語が多様であるか、多様になるからです。いくつかは単一の実装（McCarthyのLISP）から始まり、50年後にZooを手に入れました。 Common LISPは、複数の実装から始めました（異なるマシンタイプ、オペレーティングシステム、異なるコンパイラテクノロジなど）。
今日LISPは言語のファミリーであり、単一の言語ではありません。どの言語がその家族に属しているかどうかについてのコンセンサスすらありません。チェックする基準（S式、関数、リストなど）があるかもしれませんが、すべてのLISP方言がこれらすべての基準をサポートしているわけではありません。言語設計者はさまざまな機能を試し、多かれ少なかれLISPのような言語をたくさん手に入れました。
Common LISPを見ると、約3つまたは4つの異なるアクティブな商用ベンダーがあります。それらを1つのオファリングの背後に置くようにしてください！動作しません。次に、さまざまな目標を持つアクティブなオープンソース実装がたくさんあります。1つはCにコンパイルし、もう1つはCで記述し、1つは高速最適化コンパイラを使用しようとし、もう1つはネイティブコンパイルを使用してmiddlleグラウンドを作成しようとします。 JVM ...など。メンテナに実装をやめるように言ってみてください！
スキームには約100の実装があります。多くの人が死んでいるか、ほとんどが死んでいます。少なくとも10から20がアクティブです。いくつかは趣味のプロジェクトです。大学のプロジェクトもあれば、企業のプロジェクトもあります。 ユーザーにはさまざまなニーズがあります。 1つはゲーム用のリアルタイムGCが必要であり、もう1つはCに埋め込む必要があり、もう1つは教育目的のベアボーンコンストラクトのみが必要です。開発者に実装をハッキングしないように指示する方法。
次に、Commmon LISPが気に入らない人もいます（大きすぎる、古すぎる、機能が不十分、オブジェクト指向が十分でない、速度が速すぎる、速度が不十分など）。スキームが気に入らない人もいます（アカデミックすぎる、小さすぎる、拡張性がない、機能的すぎる、機能が不十分、モジュールがない、モジュールが間違っている、マクロが適切でないなど）。
次に、誰かがObjective-Cと組み合わせたLISPを必要とし、Nuを取得します。誰かが.net用のLISPをハッキングします。次に、並行性と斬新なアイデアを備えたLISPを入手し、Clojureを入手します。
それは言語の進化です。それはカンブリア紀の爆発のようなものです（たくさんの新しい動物が現れたとき）。死ぬ人もいれば、生き続ける人もいれば、新しい人も現れるでしょう。ある時点で、最先端の機能を取り入れたいくつかの方言が表示されます（70年代/ 80年代のLISPの関数型プログラミングを備えたすべてのスキームと80年代のMacLispのようなすべての共通LISP）-これにより、一部の方言がほとんど消えます（つまり、Standard LISP、InterLispなど）。
Common LISPは、LISP方言のワニです。それは非常に古いデザイン（1億年）で、ほとんど変更がなく、少し恐ろしいように見えます、そして時々それはいくつかの若いものを食べます...
「LISP」はとても広い言語の説明だからだと思います。私が知っているすべてのlispに共通するのは、ほとんどのものが角かっこで囲まれていて、プレフィックス関数表記を使用していることだけです。例えば
(fun (+ 3 4))
ただし、他のほとんどすべては実装間で異なる可能性があります。 SchemeとCLは完全に異なる言語であり、そのように考える必要があります。
LISPコミュニティを断片化して呼び出すことは、「Cのような」コミュニティを断片化して呼び出すことに似ていると思います。それはc、c ++、d、Java、c＃、go、javascript、python、そして私が考えることができない他の多くの言語を持っています。
要約すると、LISPは実際の言語実装というよりも言語プロパティ（ガベージコレクション、静的型付けなど）であるため、多くの言語がガベージコレクションを持っているように、LISPのようなプロパティを持っている言語がたくさんあるのはまったく普通のことです。
LISPはハッカー文化から生まれ、その精神を維持しているからだと思います。ハッカー文化は、「より良い」というあなたの信念に従って、何かを取り、それを「より良い」ものにすることです。
ですから、意見の分かれるハッカーがたくさんいて、修正の文化があると、断片化が起こります。 Scheme 、 Common LISP 、 [〜＃〜] elisp [〜＃〜] 、 Arc を取得します。これらはすべてかなり異なる言語ですが、同時にすべて「LISP」です。
では、なぜコミュニティは断片化されているのでしょうか。まあ、私はそれについて時間と成熟度を非難します。言語は50歳です！ :-)
SchemeとCommonLISPが標準化されています。 SBCLは事実上のオープンソースLISPのようであり、その使用方法についてはたくさんの例があります。それは速くて無料です。 ClozureCLもかなり良さそうです。
PLTスキームは事実上のオープンソーススキームのようであり、その使用方法の例はたくさんあります。それは速くて無料です。
CL HyperSpecは、私にはJavaDocと同じくらい良いようです。
コミュニティの断片化に関しては、これには標準やリソースがほとんどないと思います。これは、最近まで比較的小さなコミュニティであったものとはるかに関係があると思います。
Clojureは、新世代のコーダーのLISPになる良いチャンスだと思います。
おそらく私のポイントは、非常に人気のある実装であり、まとまりのあるコミュニティの錯覚を与えるために必要なすべてです。
LISPはBASICほど断片化されていません。
そこには非常に多くの方言とBASICのバージョンがあり、私は数え切れません。
最も一般的に使用される実装（MS VB）でさえ、バージョン間で異なります。
Common LISPの実装がたくさんあるという事実は、良いことだと考えるべきです。実際、Common LISPの無料実装の数が、C++の無料実装とほぼ同じであることを考えると、言語の相対的な人気を考えると、注目に値します。
無料のCommonLISP実装には、CMU CL、SBCL、OpenMCL/Clozure CL、CLISP、GCL、およびECLが含まれます。
無料のC++実装には、G ++（CygwinおよびMinGW32バリアントを使用）、Digital Mars、Open Watcom、Borland C++（レガシー？）、およびCINT（インタープリター）が含まれます。 C++用のさまざまなSTL実装もあります。
SchemeとCommonLISPに関しては、確かに不正確なアナロジーですが、SchemeはCommon LISPに対して、CはC++に対してであると考える場合があります。つまり、SchemeとCは小さくエレガントですが、CommonLISPとC++は大きくて（間違いなく）大規模なアプリケーションに適しています。
2つの考えられる要因：
LISP言語は、C/C++/Rubyなどの他の言語と比較してそれほど人気がありません。それだけで、断片化されたコミュニティのような錯覚を与える可能性があります。他の言語コミュニティでも同様の断片化が存在する可能性がありますが、コミュニティが大きいほど断片が大きくなります。
LISP言語は、ほとんどの言語よりも実装が簡単です。私は人々が楽しみのために作ったたくさんの「おもちゃの」LISP実装、特定のタスクを解決するためのたくさんの「適切な」LISP実装を見てきました。たとえば、Pythonインタプリタ（私は約.. 5を知っていますが、そのほとんどは一般的に交換可能です）よりもはるかに多くのLISP実装があります。
新しい言語であるClojureのような有望なプロジェクトがあります。これは明確な目標（並行性）を持ち、「歴史的な手荷物」が少なく、インストール/セットアップが簡単で、Javaのライブラリ「エコシステム」に便乗でき、ドキュメントを備えた優れたサイトがあります/ライブラリ、および公式のメーリングリストがあります。これは、しばらく前にCommon LISPを学ぼうとしたときに遭遇したすべての問題をほぼチェックし、より集中化されたコミュニティを奨励します。
各実装は固有の場所で最適であるため、多くの実装を持つことは有益です。そして、現代の主流言語には、とにかく1つの実装がありません。 Pythonについて考えてみましょう。その主な実装はCPythonですが、JPythonのおかげでJVMでもPythonを実行できます。StacklessPythonのおかげで、大規模な同時実行が可能です。マイクロスレッドのおかげで;など。このような実装はいくつかの点で互換性がありません。JPythonはJavaとシームレスに統合されますが、CPythonは統合されません。Rubyでも同じです。
望まないのは、ボーンと互換性のない多くの実装があることです。これはSchemeの場合です。この場合、Schemerはライブラリのインポート/エクスポート方法について合意できないため、多くのコードを書き直さずに実装間でライブラリを共有することはできません。 Common LISPライブラリであるOTOHは、コア領域で標準化されているため、移植性が高く、各実装の特性を処理するコードを条件付きで記述する機能があります。実際、最近では、Common LISPは、主流の言語と同じように、その実装によって定義されていると言うかもしれません（ASDFパッケージインストールライブラリについて考えてみてください）。
私の見解では、LISPは小さな言語なので、実装が簡単です（Java、C＃、Cなどと比較してください）。
注：それは確かにそれほど小さくはないという多くのコメントが私の主張を見逃しています。もっと正確に言えば、これはエントリーポイントの価格になります。よく知られている主流言語をコンパイルするa VMを構築することは、LISPを扱うa VMを構築することと比較して、かなり難しいです。これにより、小規模な構築が容易になります。小さなプロジェクトの周りのコミュニティ。現在、ライブラリと仕様は完全に実装されている場合とされていない場合がありますが、価値提案はまだあります。R5RSが確かに範囲内にない典型的な例を閉じてください。