一部の言語コミュニティ（たとえば、RubyおよびPython）は断片化を防ぐことができましたが、他のコミュニティ（たとえば、LISPまたはML）はできませんでしたか？
「LISP」（または「LISPのような」）という用語は、Common LISP、Scheme、Arcなどのさまざまな言語を包括するものです。 MLのように、他の言語コミュニティにも同様の断片化があります。
ただし、RubyとPythonはどちらもこの運命を回避することに成功しました。この場合、PyPyやYARVなどの実装でイノベーションが発生し、代わりに言語自体。
RubyおよびPythonコミュニティは、言語の断片化を防ぐために特別なことをしましたか？
RubyとPythonはどちらも benevolent dictatorsを指揮しています。彼らは深く根付いた言語です一方、LISPとMLは、理論的には学界で考えられた「委員会による設計」言語に似ています。
LISPはもともとジョンマッカーシーによってコンピュータプログラムの実用的な数学表記として設計されました。彼はそれを実際のプログラミング言語として実装したことはありません。最初の実装は Steve Russell によって開発されましたが、彼は慈悲深い独裁者ではありませんでした。時間の経過とともに、LISPの多くの異なる実装が登場しました。一般的な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）と競合するものを実行するのは非常に難しいため、人々は通常気にしません。
これは欠点のように見えます-実行可能な代替を生成するのが難しい言語には、大規模の利点があります。開発者向けのリソースが1つの真の実装に集中しています。
歴史的なメモとして、Haskellコミュニティのいくつかは積極的に合併と開発努力の集中を追求し、開発コミュニティの分裂は私たちが成功しないことを意味すると認識しました。 GHCが選ばれ、擁護されました。
1つの要素は定義プラットフォームです。 Haskellの場合、プラットフォームはHaskell標準とGHCです（私は想像します）。 Rubyの場合Ruby on Rails that that "defined" the Ruby developmentプラットフォーム。Cの場合はUnixでした。
それを、LISPと比較してください。LISPには、言語がどのようなものであるかを定義するオリジナルのキックアスプラットフォームがありませんでした。私が正しく思い出せば、各LISPマシンにはモデルとメーカーによってわずかな違いがありました。一般的なLISPは、何らかの理由で定義されていませんでした。おそらく、競争が激しく、別のプラットフォームに移行することに抵抗があるためです。
もちろん、これは完全に私の側からの推測です。この考えは、ハーベイの回答に対するコメントの返信から来ました。ただし、定義プラットフォームはさまざまな形で提供されているようですが、共通の特性は、それが人気を得ているということです。
言語の開発を促進する文化を比較検討することを忘れないでください
私はまた、python/phpの開発が公に活発に行われているという事実にも重点を置いています。あなたは、誰でも/誰でも自由に利用できる標準仕様を作成している個人の1つのグループを持っています。
W3CがHTML/CSS標準で行うように。あなたは言語が達成するように設計されているもののより詳細を制御するやる気のある個人の小さなグループを持っています。すべてが公開される前に、明確に定義された仕様に入ります。
OTOH、LISPのような言語は、その言語の「最善の使用」についての見方が正しいと真に信じている教授や他の個人によって、密室で分岐しています。一部の実装は特定の点で優れているため、それらは同時に正しいことも間違っていることもあります。何もかもが最高です。
多様性がイノベーションを生み出すので、それは必ずしも悪いことではありません。 LISPのような言語は、理解の境界を押し広げるので、学習や研究に最適な言語であり続けます。
しかし、環境をイノベーションに適したものにする品質が、必ずしも安定性に有益であるとは限りません。逆に、環境を安定性に優れたものにする品質は、必ずしも創造性に優れているとは限りません。
開発がアクティブなコラボレーションに基づいている場合、個人は全体の利益のために譲歩を余儀なくされることがあります。研究に不向き/一貫性に良い。
事実、私たちはまだプログラミング言語開発の野生の西部に住んでいます。 「理想的な言語」の設計の問題は非常に大きいため、記念碑的な努力にもかかわらず、誰もそれを解決することに近づいていません。
研究/アカデミアの分野では、まだ改善と革新の余地がたくさんあります。実用的なアプリケーションで使用されているソフトウェアの指数関数的な成長があり、原動力はシンプルさと一貫性である商業部門で。
前者に特化した言語もあれば、後者に特化した言語もあります。両方に特化しようとする人は通常、どちらもうまくいかず、死んでしまいます。
どちらも、VB/C＃/ Javaのようなモノリシック言語を指します。言うのは時期尚早ですが、C＃とPythonが10年間でどのように見えるかを確認したいと思います。現在のペースで、C＃は機能性と不整合をかなり深刻に見せる速度で成長させています。優れたドキュメントがあっても、言語に含まれているすべての微妙な詳細や癖を覚えるのは非常に面倒です。1人の開発者にとってはすばらしいことですが、独自のスタイルでより多くの開発者を投入するとすぐに、コードベースの一貫性が失われます、品質は低下し、誰も勝ちません。実稼働環境でPerlが提示する困難から学ぶべきことがたくさんあると思います。
PythonやRubyのような言語は断片化されていないと言っても間違いだと思います。すでに断片化の影響が出始めています。たとえば、Python 3はPython 2と完全に下位互換性がないため、両方のバージョンを維持する必要があり、多くの既存のコードはPythonでのみ機能します2. PyPyを含むいくつかのPythonスピンオフもあります。
もう1つの要因は、言語の年齢です。最も断片化しやすいのは古い言語であり、したがって進化と改訂の圧力を受けます。 LISPは数十年前に発明されたので、そのアイデアのいくつかを取り入れ、それらを新しい言語に組み込むのに十分な時間があります。 Cは、断片化された言語のもう1つの例です。 Cには言語自体に対する本当に大きなリビジョンが1つしかありませんが（K＆RからANSIへ）、C++、Not Quite Cなど、Cのような構文を共有するその他すべてのスピンオフがありました。
Ruby自体は、以前の言語の「断片化」です（そうする場合）。 C、Smalltalk、Perlなどのアイデアが組み込まれているため、現在は言語doingが断片化されています。今後、他の言語とのRubyのさらなる畳み込みが見られなくなる可能性がある理由はわかりません。
LISPは非常に強力なモデルであり、これまでに考えられた中で最も驚くべき言語であるため、断片化されています。今日のほとんどの言語は、LISPで最初に実装されたものを借りているため、すべての言語がこの特定の断片化の一部であると言うことができます。たとえば、SmalltalkはLISPに強く影響を受けており、RubyはSmalltalkに強く影響を受けています。JavaScriptはJava変装のLISPなどです。すべて接続されており、すべての言語の発明者が彼を選択しています。他の言語からのお気に入りの作品。
もう1つの要因は、LISPが実装するのにおそらく最も簡単なプログラミングコンセプトであることです。これが、何度も何度も行われる理由です。
LISPに似た言語は基本的で理論的すぎて劇的に変えることはできません。文法上の変更（コマンドの名前を変更するだけではありません）は、その背後にある関数型プログラミング理論に適合しません。
しかし、言語があるという事実like LISPは、とにかく「変更」がLISPに対してすでに行われたことを示しています。言い換えれば、LISPまたはその背後にある理論に触発されて、それに似た新しい言語を作った人々によって作られた言語があります。
Pythonに触発された多くの言語もあります。例えば。 Julia、CoffeeScriptなど。空白に敏感なオブジェクト指向言語の独自のファミリを形成します。
Pythonのような言語の基本的な基本は決して変更されません。Pythonはオブジェクト指向であるため、C++とJavaですが、動的なので、多くのスクリプト言語に似ています。
さて、実際に言語を気にするのは誰ですか？重要なのは目的です。フランス語はラテン語に似ていますが、フランス語を理解する女の子はとても熱くなります;）