この回答には、さまざまな言語がプロジェクトに明確なメリットをもたらすことができる理由に関する優れたカバレッジとリンクがあります。ただし、プロジェクトが最終的に複数の言語を使用するようになる理由には、言語の適合性だけでなく、それ以上のものがあります。
プロジェクトは、主に次の6つの理由で複数の言語を使用します。
- 他の言語で書かれたコードを再利用することの費用便益。
- レガシーコードを含めて対応する必要性。
- 特定の言語のコーダーの可用性;
- 特殊なニーズのための特別な言語の必要性;
- レガシー言語のバイアス; そして
- 不十分なプロジェクト管理（計画外の多言語使用）。
理由1〜4は、直接対処することで、プロジェクトをより速く、より効率的に、より高品質の製品で、より簡単に長期的にサポートできるという意味で、肯定的な理由です。理由5および6は否定的であり、必要な変更に対する抵抗の症状、計画の不備、効果のない管理、またはこれらすべての要因の何らかの組み合わせです。残念ながら、これらのマイナス要因は、「偶発的な」多言語使用の一般的な原因です。
再利用のコストメリットである理由1は、オープンソースソフトウェアのより大きな役割と、Webで適切なコードコンポーネントを見つける機能の向上の両方により、プロジェクトで複数の言語の使用を許可するますます強力な理由になっています。過去数十年の「すべてを社内でコーディングしましょう」という哲学は、経済的現実に直面して衰退し続けており、基本的に新しいプロジェクトにとって最も費用対効果の高いアプローチではありません。これにより、プロジェクト内で単一言語の使用を厳密に実施する機会が少なくなります。
特に、適切に管理されたオープンソースコンポーネントを再利用するプロジェクトの場合、複数の言語を使用すると、再利用されたコンポーネントが適切に設計されたインターフェイスの背後に隠れ、ゼロコストの外部グループによって個別に維持されるため、全体的なコスト面で大きなメリットが得られます。ベストケースのシナリオでは、この種の再利用による言語の混合は、オペレーティングシステムコンポーネントを使用するよりもプロジェクトにとってコストがかかりません。このアプローチの価値の良い例は、Microsoftのブラウザでのオープンソースソフトウェアの大規模な採用ほど良くありません。
理由2（レガシーコードに対応する必要性）は、大規模なプロジェクトの危険性では無視されます。しかし、レガシーコードが多くの問題を引き起こす可能性があり、新しい言語の新しいコードで簡単に置き換えることができると単純に仮定すると、非常に危険です。レガシーコードは、たとえ悪いレガシーコードであっても、レガシー製品を使用するコミュニティが期待する機能の暗黙的な「契約」に相当するものを含むことがよくあります。そのコミュニティは、企業の主要な収入源であるか、政府のソフトウェアのサポートの主なターゲットであることがよくあります。その暗示された契約を単に破棄することで、気づいている顧客を大勢追いかけ、他のオプションがすぐに利用可能な場合、一晩で会社を破産させることができます。
同時に、ない古い言語で古いコードを交換することは卸売交換と同じくらい危険なことができます。最悪の例は米国退役軍人局であり、コンピューター科学者ではなく医師によって設計されたMUMPS（冗談なし）と呼ばれる言語でコーディングされた多数の重要なシステムがあります。ムンプスを学びたい人は誰もいませんし、それを知っている人は文字通り死にかけています。したがって、プログラマは、他のより一般的で、より強力で、より保守された言語の使用に前進しようとしても、MUMPSに対応する必要があります。
このタイプの多言語使用には、慎重な計画が必要です。その計画は、一方で何十年もの顧客の知識を失い、他方でソフトウェアをサポートする能力を失うことの間でナイフエッジをナビゲートしなければなりません。明確に定義されたインターフェースの背後にある古いコードを分離し、その動作が十分に文書化された後に新しいより強力なコードが古いコードを置き換えることを可能にする技術が役立ちます。しかし、このレガシーシナリオは決して簡単なものではなく、幅広い規模の多くの企業や組織が消滅する原因となっています（今後もそうであり続けます）。
理由3、さまざまな言語のコーダーの可用性は、プロジェクトが危険にさらすことを無視する実用的な要因です。ただし、プロジェクトの主催者は、特定の言語が彼らの目標に最適であると（正しくまたは誤って）感じる場合があります。新しい言語を学ぼうとするプログラマの曲線。
より合理的なアプローチは、機能分野に基づいてプロジェクトの言語ニーズを分析することです。たとえば、プロジェクトを注意深く見てみると、あまり使用されていない言語でのコーディングの専門知識を必要とする、独自のアルゴリズムを実装するための高価値コードの小さな「頂点」しかないことがわかります。大規模なプロジェクトの他の部分は、より一般的な言語で、または（さらに良い）適切に管理されたオープンソース製品で簡単に対応できます。したがって、言語のニーズによってプロジェクトを分析すると、特別な言語で特別な専門知識を雇用またはレンタルするためのはるかに現実的で費用対効果の高いアプローチを提供でき、単一プロジェクト内の言語間のインターフェースを強化するのにも役立ちます。
さまざまなニーズに応じてさまざまな言語を使用する理由4は、そのような種類のプロジェクトニーズの分析を実行することから直ちにスムーズに進みます。1つのプロジェクト内でサポートする言語が多すぎると、サポートとコンポーネント間のインターフェースの両方が複雑になり、組み合わせが複雑になる可能性があるため、これにも注意が必要です。コスト面で最も安全なルートは、特にカスタマイズ以外のほとんどでプロジェクトのニーズを満たすことができる優れたパッケージが存在する場合は特に、再利用の最大機会を最初に見つけることです。次に、特定されたニーズの大部分に対処できる少数の言語について、何らかの決定を行う必要があります。再利用集約型の開発では、これは多くの場合グルーコードの一種になります。
一般に、プロジェクトの一部のメンバーが他のメンバーと同じであるという理由だけで、非常に類似した機能を持つ複数の言語を選択することはお勧めできません。ただし、特殊な言語スキルの恩恵を受ける、明確に定義された機能サブセットがある場合、新しいコード開発に複数の言語を使用する十分な理由になります。
使用される言語の必要な変更に対する抵抗5が、プロジェクトの深刻な混乱と内戦の原因になります。ユーザーとしてDaveoこの回答に関するコメントで指摘されているように、一部のプロジェクト担当者にとっては変更は非常に難しい場合があります。同時に、変化に対する抵抗は決して単純な問題ではありません。それがまさにそれが多くの争いを引き起こし得る理由です。レガシー言語が十分に強力である場合、レガシー言語スキルの使用はプロジェクトの生産性を強力に後押しすることができ、スムーズに動作し、品質を尊重するチームで優れた品質の製品につながる可能性があります。ただし、多くの古い言語は、高度な機能、コンポーネントの可用性、オープンソースオプション、インテリジェントツールキットのサポートの観点から、最近の言語では完了できないという事実と、レガシー言語のスキルのバランスを取る必要があります。
当時も現在も、より弱く、読みにくく、生産性の低いレガシー言語を使い続けるための最も一般的な（そして皮肉なことに、ほとんどの場合正しい）単一の議論は、古い言語がより効率的なコードの生成を可能にするというものでした。これは古い議論であり、1950年代にさかのぼります。アセンブリ言語のユーザーは、FORTRANとLISPでのプログラミングの出現をしばしばひどくresりました。現在でもコード効率の引数に有効性がある例は、オペレーティングシステムカーネルなどの処理集約型コードで見ることができます。ここでは、CはC ++よりも優れた言語のままです（ただし、単純な効率を超える理由があります）。
しかし、新しい千年紀のグローバルにネットワーク化され強力にマシンでサポートされたプロジェクト環境では、プロジェクト言語を選択するための主な議論としてのコード効率はさらに弱まりました。人工知能アプリケーションのマスマーケティングを可能にしたコンピューティングおよびネットワークハードウェアの爆発は、人間のプログラミングのコストが、非常に安価なハードウェアおよびクラウドウェアでの相対性の非効率なコード実行のコストを容易に上回ることを意味します。それが、コンポーネントライブラリ、オープンソースオプション、および高度なインテリジェントツールキットのより新しい言語でのより高い可用性と組み合わされると、効率上の理由だけで言語を保持するケースの数は非常に少なくなります。適用される場合でも、
プロジェクトがレガシー言語にとどまるより説得力のある理由は、何らかの理由でプロジェクトにスタッフを変更するオプションがほとんどないかまったくない場合です。これは、たとえば、主要なレガシー製品ラインが、既存のスタッフのみが流な言語で完全にコーディングされている場合に発生する可能性があります。そのような場合、プロジェクトは古い言語でプログラムしようとする道を進むか、新しい言語の使用方法について既存のスタッフを訓練しようとする必要があります。
レガシー言語のスタッフを新しい言語でトレーニングすることは、それ自体が危険な場合があります。私は、CからC ++に訓練されたばかりのプロジェクトのメンバーが、オブジェクト指向メソッドの利点を理解していないと誠意をもって私に不平を言ったケースを今でも思い出します。彼のコードを見たとき、彼は以前の103個のC関数を単一のC ++オブジェクトクラス用の103個のメソッドに変換していました...
より深いメッセージは、人々が数年または数十年にわたって単一の言語と言語スタイルでプログラミングを行った場合、新しい方法で「考える」ことの難しさは、優れたトレーニングプログラムでもほとんど克服できないことです。場合によっては、他の選択肢はないかもしれませんが、現在のトレンドや手法にもっと合っている若いデザイナーやプログラマーを連れてくることです。
プロジェクト管理が貧弱な理由6は、それ自体を物語っています。プロジェクトでの言語の選択と使用は、常に明示的に検討および評価されるべきであり、偶然に起こることは許されません。少なくとも、言語の選択はプロジェクトの長期的な運命とサポートコストに大きな違いをもたらす可能性があるため、常に考慮して計画する必要があります。ムンプスにならないでください！