最近この質問の答えを読んでいて、「言語は成熟している」という言葉に感動しました。

それで、「プログラミング言語は成熟している」と私が言うとき、私は実際には何を意味しているのだろうと思いましたか？通常、プログラミング言語は最初に必要性から開発されます、例えば

• 新しいプログラミングパラダイムまたは既存の言語にはない機能の新しい組み合わせを試してみてください。
• 問題を解決するか、既存の言語の制限を克服してください。
• プログラミングを教えるための言語を作成します。
• 特定の種類の問題（並行性など）を解決する言語を作成します。
• Webなどの特別なアプリケーション分野用の言語とAPIを作成します（この場合、言語はよく知られたパラダイムを再利用する可能性がありますが、API全体が新しい必要があります）。
• 競合他社を市場から追い出すための言語を作成します（この場合、作成者は、開発者を新しいプログラミング言語とプラットフォームに引き付けるために、新しい言語を既存の言語と非常に似たものにしたいと思うかもしれません）。

言語が作成された当初の動機とシナリオに関係なく、最終的に一部の言語は成熟したと見なされます。私の直感では、これは言語がその目標（少なくとも1つ）を達成したことを意味します。たとえば、「Webアプリケーションを作成するための信頼できるツールとして言語Xを使用できるようになりました」。

ただし、これは少しあいまいなので、言語が成熟していると言うときに適用される最も重要な基準（ある場合）をどのように考えるかを尋ねたいと思います。

重要な注意点

私は一般的な基準のみに関心があるため、この質問は（意図的に）言語にとらわれません。言語に依存しない回答とコメントのみを書き込んでください！特定の「言語Xは成熟している」または「どのプログラミング言語が成熟していると見なすことができる」か、または「言語Xは言語Yより成熟している」かどうかは質問していません。この質問の範囲外です。

編集

質問は、より正確にするために、によって基準私は、「ツールのサポート」、「養子縁組産業別」、「安定性」、「豊富なAPI」、「大規模なユーザーコミュニティ」、「成功したアプリケーション・レコード」、「標準化」のようなものを意味します、「クリーンで均一なセマンティクス」など。

受け入れ要因

いろんなことを組み合わせて言ってみますが、すべてが必要だとは思いません。今日成熟していると考えられているいくつかの言語は明らかにこれらのいくつかを満たさない。

私は次の組み合わせを言うでしょう：

• ツーリング：
  • mainline：少なくとも1つの安定した「公式」または広く受け入れられている（デファクトまたはベンダー推奨/サポートされている）ツールスイート（コンパイラ、インタープリタ、vm、エディタ）。
  • 代替：上記のツールのいくつかの安定した、それほど安定していない代替（クローズドまたはオープンソースのバリアント、無料または商用のバリアント、拡張機能など...）。
• コミュニティ：アクティブ、しかし必ずしも大きくない信者と貢献者のグループ。
• 認識：
  • 一部の産業関係者によるある程度の認識と使用（ニッチな場合でも）。
  • 大衆文化でのある程度の認識（ニッチでも）。

名声、認識、成熟度について

ここでの差別化要因は、大規模な、または多数の基準バリデーターではなく、強力でアクティブな基準バリデーターがあることに注意してください。明確にするために、これらの非常に異なる例を検討してください：

• Rubyは長い間、大規模なコミュニティの支援、公式のリファレンス実装などを備えた言語でしたが、その大まかなエッジを解決するまで、成熟したとは見なされませんでした。成熟する前は有名でした。

• 一方で、かつては非常に広く使用されていた言語（COBOL、FORTRAN ...）の一部は、現在はあまり見えませんが、あらゆる意味で成熟しています。彼らはかつて有名で成熟していた。

• また、一部のニッチ言語は、その小さな（しかし確立された）市場への浸透にもかかわらず、間違いなく成熟していると私は考えています。OberonまたはLimboを検討してください。彼らは成熟していますが、有名になったことはありません。Rのような他のものは、その「ニッチ」が実際にはニッチではないという点で比較的有名です（人々がScalaやClojureのような「ニッチな言語」などと呼ぶと、間違いなく私を悩ませます）。ただし、アプリケーションの分野は異なります。まさにあなたがメインストリームと呼ぶものです。

安定性について

とにかく安定しているものは何ですか？それはかなり相対的です...

• コンプライアンス？
  • 標準に（もしあれば）？
  • 参照実装（ある場合）に？
• バグの数は？（ほとんど良い方法ではありません）
• 重要な環境で使用しますか？

一般的に、安定性とは、言語のツールキットを使用して平均的な仕事をしているときに日常的に驚かないことを意味します。言語を使用して何かを行おうとすると、何が起こるべきか、またはすべきでないかについて決定的な答えを得ることができます。私のプログラムのビルド時でもランタイム時でも、そのツールキット。

しかし、スマートフォンアプリを書く人にとっての安定性と、医療または航空電子工学システムを書く人にとっての安定性は、別の種類の鳥です。

私は実際には数年前に同じことを考えていました。当時、その問題を解決するために必要な機能のほとんどを備えている言語は成熟している（つまり、タイプxの問題を解決するのに適している）と判断しました。つまり、自分で作成しなければならない特定の問題解決ツールと、すでに言語に付属しているツールの数です。あなたのコメントに従って、私は言語固有の例を削除し、それを言語にとらわれないものに置き換えます：

私は基本的に、「ヘルパー」および「ユーティリティ」ライブラリが多く組み込まれている言語は、それらの一部が存在しない（およびそれらを記述しなければならない-またはそれに類似したもの）言語よりも成熟していると思いましたそれら-私自身）

私が過去にこのすべてについて話しているのは、最近私はその考え方をかなり捨てて、言語の成熟度を次のように考えているからです。

• コミュニティがその言語に対してどれだけ強いか。ドキュメント、書籍、関連する例がいくつあるか。これは重要です。非常に優れた言語があり、特定のタスクには他の言語よりも適しているかもしれませんが、文書化が不十分であるため、言語の利点が決してわかりません。

• パフォーマンス。特定のタスクと特定のx実装では、その実装がより高速に実行される言語はより成熟しています。はい、これは非常に灰色の領域であり、ほとんどの言語とプラットフォームでは、比較することは困難です。ただし、特定の言語とプラットフォームでは、どれがどれより優れているかを確認するのは非常に簡単です。特定の種類の問題では、これは非常に重要です。

• バグ。そうそう。自分の目で見ない限り、考えたことはなかったでしょう。ある言語を打ちたがっているように思われたくないので、例を挙げませんが、そこには特定の言語の言語があります（より正確には、特定の言語のコンパイルおよびランタイム環境）。非常にバグが多く、信頼性がなく、何かがどのように機能するかを見積もることができなくなります。これが当てはまる場合、私にとって言語の成熟度は大きく低下します。

私が言語をより成熟したものとして考える方法を切り替えた理由は次のとおりです。

• まず、言語に大量のヘルパーライブラリとユーティリティがあるという事実は、それらが実際に有用であるとは限らない場合があります。これらのライブラリはまだ汎用的であり、特定のニーズから遠く離れている可能性があるため、結局、自分自身の一部を書き換えて、より効率的な問題固有の解決策を講じる傾向があります。

• さらに、言語とプラットフォームのパフォーマンスやドキュメントなどは、ライブラリがない場合よりも補償するのが難しいものです。言語xとプラットフォームyで記述したコードが遅い場合、自分で最適化することは、自分よりも（おそらく賢い）人々のコホートが最適化を行った言語x2とプラットフォームy2で置き換えるほど優れたものにはなりません。同じことがドキュメンテーションにも当てはまります。それがないと、概念の実証、試行錯誤、ソースコードとユニットテストのコードの調査に時間を費やすことになり、何かを行う方法を確認できます。これらすべてを試しても、選択したソリューションが最も適しているかどうかは、言語クリエーターが意図したとおりに機能するため、わかりません。