一部の言語コミュニティ（RubyやPythonなど）が断片化を防止できる一方で、他の言語コミュニティ（LispやMLなど）ができないのはどうしてですか？

「Lisp」（または「Lispライク」）という用語は、Common Lisp、Scheme、Arcなど、さまざまな言語の総称です。MLなど、他の言語コミュニティにも同様の断片化があります。

ただし、RubyとPythonはどちらも、言語自体に変更を加えるのではなく、実装（PyPyやYARVなど）でイノベーションが発生したこの運命を回避することに成功しています。

RubyとPythonのコミュニティは、言語の断片化を防ぐために特別なことをしましたか？

RubyとPythonの両方には、慈悲深い独裁者がいます。それらは、実用的な懸念に深く根ざした言語です。これらはおそらくフラグメンテーションを抑制する最も重要な要因です。一方、LispとMLは、理論的には、学界で考案された「委員会による設計」言語に似ています。

Lispは、もともとJohn McCarthyによってコンピュータープログラムの実用的な数学表記として設計されました。彼は実際のプログラミング言語として実装したことはありません。最初の実装はSteve Russellによって開発されましたが、彼は慈悲深い独裁者ではありませんでした。やがて、Lispのさまざまな実装が登場しました。Common Lispはそれらを標準化する試みでした。

Lispはより多くの言語の「ファミリー」です。MLも同様で、Lispへの同様の進化的パスをたどりました。

考えられる要因の1つは、単に年齢です。LispとMLはPythonとRubyよりずっと古いです：

• Lisp：1958

• ML：1973

• Python：1991

• ルビー：1995

LispとMLは、明らかにハードウェア機能のより大きな変化、コンピューターサイエンスのより多くの傾向、および何かを研究するために非常に多くの博士課程の学生を見てきました。

基本的にはすべて実装定義の言語です

既存のコードとほぼ互換性のある言語の新しい実装を作成するのが簡単な場合、ハッカーはハッカーであり、それを実行します。いずれかの時点で、誰もがLisp実装を作成します。MLコンパイラーは、言語設計の大学院生にとってほぼ必須です。言語は、結局のところ、よく文書化されています。

一方、アドホック言語と実装定義言語があります。または、実行可能な代替実装を作成するための重要な障壁であるほど複雑な言語：

• ルビー; perl; python-実行可能な代替物を生成するために実装定義が多すぎる
• ghc haskellおよびerlang-明確に定義されていますが、ghc（またはerlang）と競合するものを実行するのは非常に難しく、人々は通常は気にしません

これは欠点のように見えます-実行可能な代替を作成するのが難しすぎる言語には大きな利点があります：開発者のリソースが乏しいため、真の実装に集中しています。

歴史的なメモとして、Haskellコミュニティのいくつかは、開発と開発の努力の統合と集中を積極的に追求しました。開発コミュニティの分裂は成功しないことを意味します。GHCが選ばれ、優勝しました。

一つの要因は、プラットフォームを定義することです。Haskellの場合、プラットフォームはHaskellの標準であり、GHCです（想像できます）。Rubyの場合、Ruby開発プラットフォームを「定義」したのはRuby on Railsでした。Cの場合はUnixでした。

Lispと比較してください。Lispでは、言語がどのようなものであるかを定義する独自のキックプラットフォームはありませんでした。正しく思い出せば、各Lispマシンにはモデルとメーカーによってわずかな違いがありました。Common Lispは何らかの理由で定義されていませんでした。競争が激しく、別のプラットフォームに移行するのをためらっている可能性があります。

もちろん、これは私の側からの完全な推測です。この考えは、ハーベイの答えに対するコメントの回答から来ました。ただし、定義するプラットフォームにはさまざまな形があるように見えますが、一般的な特性は、それが人気を得ていることです。

言語の発展を促進する文化を評価することを忘れないでください

また、python / phpでの開発は積極的に公共で行われているという事実を重視します。誰でも誰でも自由に利用できる標準仕様を作成する個人のグループが1つあります。

W3CがHTML / CSS標準で行うように。あなたは言語が達成するために設計されているもののより詳細を制御する意欲的な個人の小さなグループを持っています。すべてが公開される前に、明確に定義された仕様に組み込まれます。

LISPのような言語は、言語の「最適な使用」に関する彼らの見方が正しいと真に信じている教授や他の個人によって、密室で分岐しています。一部の実装は特定の点で優れているため、それらは同時に正しいことと間違っていることがあります。どれも最高のものではありません。

多様性はイノベーションを生み出すため、必ずしも悪いことではありません。LISPのような言語は、理解の境界を押し広げるため、学習および研究に最適な言語です。

しかし、環境を革新に適したものにする性質は、安定性に必ずしも有益ではありません。逆に、環境を安定させるのに適した性質は、必ずしも創造性に適しているとは限りません。

開発がアクティブなコラボレーションに基づいている場合、個人がより大きな全体の利益のために譲歩を強いられることがあります。研究には不向き/一貫性には良い。

事実、私たちはプログラミング言語開発の未開の地に住んでいます。「理想的な言語」を設計する問題は非常に大きいので、記念碑的な努力にもかかわらず、誰もそれを解決することに近づいていません。

研究/学界では、まだ改善と革新の余地がたくさんあります。商業部門では、実際のアプリケーションで使用されるソフトウェアの指数関数的な成長があり、原動力は単純さと一貫性です。

前者に特化した言語もあれば、後者に特化した言語もあります。両方に特化しようとするものは、通常あまりうまくいかず、死に絶えます。

両方とも、私はVB / C＃/ Javaのようなモノリシック言語に言及しています。言うのは時期尚早ですが、10年後にC＃とPythonがどのように見えるかを見てみたいと思います。現在のペースでは、C＃は機能と一貫性をかなり厳しく見せる速度で成長しています。優れたドキュメントであっても、言語に含まれるすべての微妙な詳細や癖を覚えるのは非常に苦痛です。単一の開発者にとっては素晴らしいことですが、独自のスタイルを持つ開発者を投入するとすぐに、コードベースの一貫性が失われ、品質が低下し、誰も勝ちません。Perlが実稼働環境で提示する困難から学ぶべきことがたくさんあると思います。

PythonやRubyのような言語は断片化されていないと言うのは正しくないと思います。すでに断片化の影響が見られ始めています。たとえば、Python 3はPython 2と完全に後方互換性があるわけではないため、両方のバージョンを維持する必要があり、既存のコードの多くはPython 2でのみ機能します。PyPyを含むPythonスピンオフもあります。

別の要因は、言語の年齢です。フラグメンテーションに最もさらされているのは古い言語であるため、進化と改訂の圧力を受けます。Lispは数十年前に発明されたので、そのアイデアのいくつかを取り入れて新しい言語に組み込む十分な時間がありました。Cは、断片化された言語の別の例です。Cには言語自体に1つの本当に大きなリビジョン（K＆RからANSI）しかありませんでしたが、C ++、Not Quite C、およびCのような構文を共有する他のすべてを含む多数のスピンオフがありました。

Ruby自体は、以前の言語の「断片化」です（もしそうなら）。C、Smalltalk、Perl（など）のアイデアが組み込まれているため、現在は断片化を行う言語です。将来、Rubyと他の言語とのさらなるコンボリューションが見られない理由はわかりません。

Lispは非常に強力なモデルであり、かつてないほど驚くべき言語であるため、断片化されています。今日のほとんどの言語は、最初にLispで実装されたものを借用しているため、すべての言語はこの特定の断片化の一部であると言えます。たとえば、SmalltalkはLispから大きな影響を受け、RubyはSmalltalkから大きな影響を受けました。JavaScriptはJava変装のLispなどです。すべてが接続されており、すべての言語発明者がお気に入りの作品を他の言語から選択します。

もう1つの要因は、おそらくLispを実装するのが最も簡単なプログラミングコンセプトであることです。これが、Lispが何度も何度も実行される理由です。

Lispに似た言語は、基本的かつ理論的すぎて劇的に変更できません。文法的な変更（コマンドの名前を変更するだけではありません）は、それらの背後にある関数型プログラミング理論に適合しません。

しかし、Lispのような言語があるという事実は、とにかく「変更」がすでにLispに対して行われたことを示しています。言い換えれば、Lispまたはその背後にある理論に触発され、同様の新しい言語を作成した人々によって作られた言語があります。

Pythonに触発された言語もたくさんあります。例えば、ジュリア、CoffeeScriptなど、独自のホワイトスペースに敏感なオブジェクト指向言語のファミリーを形成します。

Pythonのような言語の基本的な基本は実際に変わることはないと思います。Pythonはオブジェクト指向であるため、C ++およびJavaと類似していますが、動的であるため、多くのスクリプト言語とも類似しています。

誰が実際に言語を気にしているのですか？大切なのは目的です：フランス語はラテン語に似ていますが、フランス語を理解している女の子はずっと暑いです;）