1つの製品またはソフトウェアの開発に複数のプログラミング言語が使用されるのはなぜですか？
私はコンピュータサイエンスの修士号を取得しようとする最近の大学院生です。私は本当に興味をそそられ、それらに貢献することを奨励する複数のオープンソースプロジェクトに遭遇しました（いくつか挙げると、CloudStack、OpenStack、moby、およびKubernetes）。それらの大部分が共通して持っていることの1つは、複数のプログラミング言語の使用です（Java + Python + GoまたはPython + C++ + Ruby）私はすでにこの別の質問を見てきました。これは、複数のプログラミング言語が互いに通信するためにどのように作成されるかを扱います： 2つの異なる2つの異なるプログラミングを持つ方法言語は相互作用しますか？
企業が複数のプログラミング言語を使用するように要求する要件を理解したいと思います。ソフトウェアアーキテクトまたはプロジェクトリーダーが「タスク1には言語Xを使用し、タスク2には言語Yを使用することを提案している」と言うのは、どのような要件または要件のタイプですか。同じ製品やソフトウェアで複数のプログラミング言語が使用されている理由が理解できないようです。
この回答 は、優れたカバレッジと、さまざまな言語がプロジェクトに明確な利点を提供できる理由に関するリンクがあります。ただし、プロジェクトが複数の言語を使用することになる理由には、言語の適合性だけではありません。
プロジェクトは、主に6つの理由で複数の言語を使用します。
- 他の言語で書かれたコードを再利用することのコスト上のメリット。
- レガシーコードを含めて対応する必要性。
- 特定の言語のコーダーの可用性。
- 特殊なニーズのための特殊言語の必要性。
- 従来の言語の偏見;そして
- プロジェクト管理が不十分（計画外の多言語使用）。
理由1〜4は、直接対処することで、プロジェクトをより速く、より効率的に、より高品質の製品で、より簡単に長期的にサポートできるという意味で、肯定的な理由です。理由5および6は否定的であり、必要な変更に対する抵抗の兆候、計画の不備、効果のない管理、またはこれらすべての要因のいくつかの組み合わせです。残念ながら、これらのマイナス要因は、「偶然の」多言語使用の一般的な原因です。
理由1は再利用のコストメリットであり、プロジェクトの複数の言語の使用を許可する理由がますます大きくなっています。オープンソースソフトウェアとWeb上の適切なコードコンポーネントを見つけるための改善された機能。過去数十年の「すべてを内部でコード化しよう」という哲学は、経済の現実に直面して衰退し続けており、基本的に、いかなる新しいプロジェクトにとっても最も費用対効果の高いアプローチではありません。これにより、プロジェクト内での単一言語の使用を厳密に実施する機会が一般的ではなくなります。
特に、適切に管理されたオープンソースコンポーネントを再利用するプロジェクトの場合、再利用されたコンポーネントは両方とも適切に設計されたインターフェースの背後に隠されており、コストのかからない外部グループによって独立して維持されるため、複数の言語を使用すると、全体的なコスト面で大きなメリットがあります。最良のシナリオでは、この種の再利用による言語の混在は、オペレーティングシステムコンポーネントを使用するよりもプロジェクトにコストがかかりません。このアプローチの価値の良い例は、マイクロソフトのブラウザーでのオープンソースソフトウェアの大規模な採用ほどよくわかりません。
理由2（レガシーコードに対応する必要がある）は、大規模なプロジェクトの危険では無視されます。ただし、レガシーコードが引き起こす問題の多くは、単純に新しい言語の新しいコードに簡単に置き換えることができると想定すると、非常にリスクが高くなる可能性があります。レガシーコードは、悪いレガシーコードでさえ、多くの場合、レガシー製品を使用するコミュニティが期待する機能の暗黙の「契約」に相当するものを含みます。そのコミュニティは、企業の主要な収入源である場合が多く、政府ソフトウェアのサポートの主なターゲットとなっています。暗黙の契約を破棄するだけで顧客を追い詰め、他のオプションがすぐに利用できる場合は、会社を一夜で破産させることができます。
同時に、古いコードで古いコードを置き換えるしないのは、大規模に置き換えるのと同じくらい危険です。最悪の例は米国退役軍人局で、コンピューター科学者ではなく医師によって設計されたMUMPS（冗談ではありません）と呼ばれる言語でコーディングされた重要なシステムが多数あります。 MUMPSを学びたいと思う人は誰もいませんし、それを知っている人たちは文字通り死んでいきます。したがって、プログラマーは、他のより一般的で、より強力で、より保守された言語を使用しようとする場合でも、MUMPSに対応する必要があります。
このタイプの多言語使用には注意深い計画が必要です。その計画は、一方では何十年にもわたる顧客の知識を失い、他方ではソフトウェアをサポートする能力を失うことの間でナイフEdgeをナビゲートする必要があります。明確に定義されたインターフェースの背後にある古いコードを分離し、その動作が十分に文書化された後、新しいより強力なコードが古いコードを置き換えることを可能にする手法が役立ちます。しかし、このレガシーシナリオは決して簡単なものではなく、さまざまな規模の多くの企業や組織が消滅する原因となってきました。
理由3、さまざまな言語のコーダーの可用性は、プロジェクトが危険にさらされても無視する実用的な要素です。ただし、特定の言語が目標に最適であるとプロジェクトオーガナイザーが（正しくまたは誤って）感じる場合があります。その言語が利用可能な言語専門知識プールと矛盾する場合、製品のスケジュールと品質の両方が学習に影響します。新しい言語を学習しようとするプログラマーの曲線。
より合理的なアプローチは、機能分野に基づいてプロジェクトの言語ニーズを分析することです。たとえば、プロジェクトを注意深く見ると、価値の高いコードの小さな "頂点"しかないことがわかります。独自のアルゴリズムを実装するには、あまり一般的に使用されていない言語でのコーディングの専門知識が必要です。大規模なプロジェクトの他の部分は、より一般的な言語、または（さらに優れた）よく管理されたオープンソース製品によって容易に対応できます。したがって、言語のニーズに基づいてプロジェクトを分析すると、特別な言語で特別な専門知識を採用またはレンタルするための、より現実的で費用効果の高いアプローチを提供でき、単一のプロジェクト内の言語間のインターフェースをシャープにするのにも役立ちます。
理由4は、さまざまなニーズに応じてさまざまな言語を使用しているため、そのようなプロジェクトニーズの分析をすぐにスムーズに実行できます。単一のプロジェクト内でサポートする言語を選択しすぎると、サポートとコンポーネント間のインターフェースの両方が複雑になるため、注意が必要です。コスト面で最も安全な方法は、常に最初に再利用の最大の機会を見つけることです。特に、カスタマイズだけでプロジェクトのニーズを満たすことができる優れたパッケージが存在する場合はなおさらです。次に、特定されたニーズの大部分に対応できる少数の言語で、ある種の決定を行う必要があります。再利用が多い開発では、これはしばしば一種のグルーコードになります。
プロジェクトの一部のメンバーが他のメンバーと好んでいるという理由だけで、非常に類似した機能を持つ複数の言語を選択することは、一般にではありません。ただし、特別な言語スキルの恩恵を受ける明確に定義された明確な機能サブセットがある場合、それは、新しいコード開発に複数の言語を使用するための十分な理由になります。
理由5、使用される言語の必要な変更への抵抗は、深刻なプロジェクトの混乱と内部紛争の原因となる可能性があります。ユーザー Daveo がこの回答のコメントで指摘したように、一部のプロジェクトスタッフにとって変更は非常に難しい場合があります。同時に、変化への抵抗は決して単純な問題ではありません。それがまさにそれが多くの争いを引き起こす可能性がある理由です。レガシー言語が十分に強力である場合、レガシー言語スキルの使用はプロジェクトの生産性を大幅に向上させる可能性があり、スムーズに動作し品質を尊重するチームで優れた品質の製品につながる可能性があります。ただし、レガシー言語のスキルは、高度な機能、コンポーネントの可用性、オープンソースオプション、およびインテリジェントツールキットのサポートに関して、多くの古い言語が最近の言語と競合できなくなるという事実とバランスを取る必要があります。
当時も現在も、より弱く、可読性が低く、生産性が低いレガシー言語を引き続き使用するための最も一般的な（皮肉なことに、最も頻繁に正しい）議論は、古い言語により効率的なコードの生成が可能になるというものです。これは古い議論であり、1950年代にアセンブリ言語のユーザーがFORTRANとLISPでのプログラミングの出現に憤慨し、多くの場合それを嫌悪したときまで遡ります。今でもコード効率の引数が有効である例は、オペレーティングシステムカーネルなどの処理集約型のコードで見られます。CはC++よりも優れた言語です（ただし、単純な効率を超える理由があります）。
ただし、新世紀のグローバルにネットワーク化され、強力にマシンがサポートするプロジェクト環境では、プロジェクト言語を選択するための主要な論拠としてのコード効率はさらに弱くなっています。人工知能アプリケーションの大規模なマーケティングを可能にしたコンピューティングおよびネットワーキングハードウェアの同じ爆発はまた、人間のプログラミングのコストが、非常に安価なハードウェアおよびクラウドウェアでの相対性非効率的なコード実行のコストを容易に削減できることを意味します。それが、コンポーネントライブラリ、オープンソースオプション、および高度なインテリジェントツールキットのより最近の言語でのより大きな可用性と組み合わされると、効率上の理由だけで言語を維持するケースの数は非常に狭くなります。それが当てはまる場合でも、コミュニティの幅広いサポートを受け続けるCなどの言語を使用することに重点を置く必要があります。
プロジェクトがレガシー言語を維持するためのより説得力のある理由は、何らかの理由でプロジェクトがスタッフを変更するためのオプションがほとんどまたはまったくない場合に発生します。これは、たとえば、主要なレガシー製品ラインが、既存のスタッフだけが流暢な言語で完全にコーディングされている場合に発生する可能性があります。このような場合、プロジェクトは、古い言語でプログラミングを試みる道筋を続けるか、新しい言語を使用する方法について既存のスタッフをトレーニングする必要があります。
従来の言語のスタッフを新しい言語でトレーニングすることは、それ自体が危険である可能性があります。トレーニングを受けてCからC++に移行したばかりのプロジェクトのメンバーが、オブジェクト指向メソッドの利点を理解していないと誠実に不平を言ったケースを今でも覚えています。私が彼のコードを見ると、彼は以前の103 C関数を単一のC++オブジェクトクラスの103メソッドに変換していたので、それがどのように役立つかは正しくわかりませんでした。
より深いメッセージは、人々が数年または数十年間単一の言語と言語スタイルでプログラミングを行った場合、優れたトレーニングプログラムを使用しても、新しい方法で「考える」ことを困難にすることができるということです。場合によっては、現在のトレンドや手法にもっと精通している若いデザイナーやプログラマーを招くこと以外の選択肢はないかもしれません。
理由6、貧弱なプロジェクト管理、それ自体が語っています。言語の選択とプロジェクトでの使用は、常に明示的に考慮および評価されるべきであり、偶然に起こることは許されません。少なくとも、言語の選択はプロジェクトの長期的な運命とサポートコストに大きな違いをもたらす可能性があるため、常に考慮して計画する必要があります。 MUMPSにならないでください！
同じ製品またはソフトウェアで複数のプログラミング言語が使用されている理由が理解できないようです。
それは非常に単純です。すべてのニーズと目標に適した単一のプログラミング言語はありません。
Michael L. Scottの本を読んでください Programming Language Pragmatics
一部のプログラミング言語は、表現力と declarativity （多くのスクリプト言語だけでなく、 Agda 、 Prolog 、 [〜＃〜] lisp [〜＃〜] 、Haskell、Ocaml、...）。開発のコストが重要な場合（開発者の人間の時間とコスト）、（ランタイムのパフォーマンスが最適でなくても）それらを使用するのが適切です。
他のプログラミング言語はランタイムパフォーマンスを優先します（C++、Rust、Go、C、アセンブラーなどの通常コンパイルされた実装を備えた多くの低レベル言語、OpenCLなどの特殊言語...）。多くの場合、それらの仕様では ndefined behavior を許可しています。コードのパフォーマンスが重要な場合は、これらの言語を使用することをお勧めします。
一部の外部 libraries は特定の言語で記述されており、 [〜＃〜] abi [〜＃〜] および calling Conventions を念頭に置いています。他の言語を使用する必要があるかもしれません 外部関数インターフェース の慣習に従う必要があります。おそらく グルーコード を書くことになるでしょう。
実際には、非常に表現力豊かで（十分に熟練した開発者チームを想定すれば、開発者の生産性が向上します）、実行時に非常に高いパフォーマンスを発揮するプログラミング言語はありません。実際には、表現力とパフォーマンスの間にはトレードオフがあります。
注：ただし、プログラミング言語では遅い進歩が見られます：RustはCまたはおそらくC++よりも表現力がありますが、その実装はほぼ同じくらいパフォーマンスが高く、同等に高速な実行可能ファイルを生成するために改善される可能性があります。したがって、職業生活中に新しいプログラミング言語を学ぶ必要がありますが、 シルバーバレットなし
今日の開発コストはますます重要になっていることに注意してください（1970年代にはそうではありませんでした-当時は非常にコストのかかるコンピュータ-または一部の組み込みアプリケーションで、大規模な製品の量）。経験則（大体）は、熟練した開発者が毎年約25千行の（デバッグおよび文書化された）ソースコードを記述できることであり、これは使用するプログラミング言語にあまり依存しません。
一般的なアプローチは、大規模なアプリケーションに一部の スクリプト言語 （または一部の ドメイン固有の言語 ）を埋め込むことです。この設計思想（ドメイン固有言語に関連）は何十年もの間使用されてきました（1980年代以来、スクリプトにElispを使用して Emacs ソースコード editor が良い例です）。次に、より大きなアプリケーション内で簡単に埋め込むことができるインタープリター（ Guile 、 Lua 、 Python 、...など）を使用します。大規模なアプリケーションの内部にインタープリターを埋め込むという決定は、非常に早い時期に行われる必要があり、アーキテクチャ上の強い影響があります。次に、2つの言語を使用します。迅速に実行する必要がある低レベルのものには、CやC++などの低レベル言語を使用します。高レベルのスクリプトの場合、他のDSLまたはスクリプト言語。
また、特定のソフトウェアは、最新の オペレーティングシステム （Linux、Windows、Android、MacOSX、Hurdなどを含む）内で、いくつかの協調 プロセス を使用して実行できることにも注意してください。ある種の プロセス間通信 テクニック。 分散コンピューティング テクニック（例 クラウドコンピューティング 、HPC、クライアントサーバー、 ウェブアプリケーション ）を使用して、複数のコンピューター（またはそれらの多く）で実行することもできます。 =など）。どちらの場合も、いくつかのプログラミング言語を使用するのは簡単です（たとえば、1つのプロセスまたはコンピューターで実行されている各プログラムを独自のプログラミング言語でコーディングします）。詳しくは オペレーティングシステム：3つの簡単な部分 をご覧ください。また、 foreign function interfaces （eg [〜＃〜] jni [〜＃〜] ）、 [〜＃〜] abi [〜＃〜] s、 呼び出し規約 など...同じプログラムで複数の言語を混在させることができます（または 実行可能 ）-そして のようなコードジェネレーターが見つかります[〜＃〜] swig [〜＃〜] 支援します。
いくつかのケースでは、いくつかのプログラミング言語を混合する必要があります：Webアプリケーションは、ブラウザーで実行されている部分に対してJavascriptまたはWebassembly（ほとんどのWebブラウザー内で実行される唯一の言語）を必要とします（あるフレームワークgeneratingこれら、例えば ocsigen ）。カーネルコードは、CまたはC++がそこで必要なものを表現できないため、RDBMSクエリでSQLを使用する必要があるため、アセンブラで部分的に記述する必要があります（たとえば、スケジューラ、または割り込みの低レベル処理）。 [〜＃〜 ] gpgpu [〜＃〜] s必要 コンピュータカーネルOpenCL または [〜＃〜] cuda [〜＃〜] でコーディングCまたはC++ホストコードなどによって管理されます...一部の言語は、そのような混合を促進するように設計されています（例 asmステートメント Cで、 コードチャンク 私の後半 GCC MELT など...）。
metaprogramming 手法を使用する場合もあります。大規模なソフトウェアプロジェクトの一部には、アドホックな形式のほかのツール（おそらくプロジェクト固有のツール）によって生成されたコード（CまたはC++など）があります。 bison または [〜＃〜] antlr [〜＃〜] のようなパーサージェネレーター（不適切にコンパイラーコンパイラーと呼ばれます）が頭に浮かびますが、SWIGまたはRPCGENもあります。そして、 [〜＃〜] gcc [〜＃〜] には、12を超える特殊なC++コードジェネレーター（GCC内のすべての内部DSLに1つ）が含まれていることに注意してください。 this の例も参照してください。 metabugs は見つけにくいことに注意してください。 ブートストラップコンパイラ 、および homoiconicity および reflection についてもお読みください（学習する価値がある [〜＃〜] lisp [〜 ＃〜] 、 [〜＃〜] sbcl [〜＃〜] で遊んで、読むには [〜＃〜] sicp [〜＃〜] ; JIT-compiling[〜＃〜] gccjit [〜＃〜] のようなライブラリも参照してください。一部の大きなプログラムでは、それらを使用して実行時にコードを生成する場合があります。 Greenspunの10番目のルール ）。 FOSDEM2018での Circuit Less Traveled トークもご覧ください。
いくつかの特殊な注釈言語（DSLと見なされる可能性がある）を使用して、コードの正式な注釈を提供したい場合があります（例：証明者、静的アナライザー、コンパイラー）。 [〜＃〜] acsl [〜＃〜] を調べて Frama-C でCプログラム（安全性が重要なプログラム）に注釈を付けるか、または OpenMP = HPCのプラグマ。警告：そのような注釈を書くには、多くのスキルと開発時間が必要になる場合があります。
ところで、これは、コンパイラーとインタープリターに関するいくつかのスキルがすべての開発者に役立つことを示唆しています（コンパイラー内で作業しなくても）コンパイラを使用していなくても、 Dragon Book を読んでください。独自のインタープリターをコーディングする場合（またはDSLを設計する場合）は、 LISP In Small Pieces もお読みください。
参照してください this ＆ that ＆ that ＆ that あなたの質問に関連する私の答え。
いくつかの大規模な フリーソフトウェア プロジェクト（ github または Linuxディストリビューション から）のソースコードも調べて、インスピレーションと啓発を得ます。
また、一部のプログラミング言語は、既存の言語に（プラグマまたは comments として）注釈を追加することによって進化しました。例として、 [〜＃〜] acsl [〜＃〜] （ Frama-C によって証明を有効にするためにCプログラムに注釈を付けるコメント拡張機能）または OpenCL （GPGPUをプログラムするためのC言語）または OpenMP または OpenACC#pragmas または 一般的なLISPタイプの注釈 。
PS：プログラミング言語を混在させるには、社会的、組織的、または歴史的な理由もあります。ここではそれらを無視していますが、実際にはそのような理由が支配的であることは知っています。また読む The Mythical Man Month
多くのプロジェクトはnotが複数のプログラミング言語で構築されています。ただし、ソフトウェアを支援するために他の言語のスクリプトを使用することは一般的です。
- 個別のプログラムである管理ツールは、別の言語で書かれている場合があります。
- ライブラリとAPIは複数の言語のバインディングを提供することが多いため、開発者は好みの言語を使用できます。
- ビルドスクリプトおよび関連する開発スクリプトは、多くの場合、特殊な言語を使用しています。
- アプリケーションのエンドツーエンドのテストでは、同じ言語を使用する必要はありません。
一部のプロジェクトでは、アプリケーション内で複数の言語を使用しています。プラグインをスクリプト言語に統合できる低レベル言語のコア。一部のエコシステム（JVMや.NETなど）では、同じ言語ランタイムの複数の言語の相互運用性が優れているため、使用される正確な言語はそれほど重要ではありません。たとえば、既存のScalaライブラリを使用し、スクリプト機能をGroovyと統合するJavaでプロジェクトを書くことができます。
プロジェクトが複数のツールで構成されている場合、それらを異なる言語で開発することもできます。一貫性は良好ですが、特にオープンソースプロジェクトの場合、利用可能な開発作業がボトルネックになる可能性があります。誰かが有用なツールを開発する意思があるが、主要言語に精通していない場合、おそらくそのツールは一貫性よりも価値があります。
これには2つの形式があり、多くの組織がこの2つの中間にあります。
悪い形式-組織はめちゃくちゃであり、その取り組みに対して単一の技術的ビジョンがあることを誰も確認していません。開発者は、最も快適な言語を使用するか、新しいフレームワークまたは言語で最近実験を行い、単純な楽観主義のために単にそれを使用することにしました。
良い形-組織には、ポリグロットプログラミングに適した、本当にきれいなアーキテクチャがあります。明確に定義された境界コンテキストを使用して、アプリケーションを独立したコンポーネントに分離します。この組み合わせにより、特定のコンポーネントを最も簡単に作成できるプログラミング言語を選択できます。
現実-通常、後者よりも前者です。いくつかの企業が、ビジネスドメインとWebサーバーに1つの言語を選択し、多くの場合、データベース管理に3番目の言語を選択しています。これは、技術的には問題ありませんが、すぐに技術的理解が不足します（またはスタッフの意見を聞くことを拒否します）。つまり、3つすべてが一緒にぼやけて大きな混乱に陥り、混乱の特定の部分を解決するのに適切な言語がさらに導入されることがよくあります。
私は、32年間実行されているプログラミングプロジェクトの例を提供できます。オープンソースというよりは商用です。
コアは、プロジェクト専用に作成されたドメイン固有の言語で記述されています。これは、特にロールバックを基本アーキテクチャに統合しているため非常に有用であることが証明されていますが、Cコードにコンパイルされ、プラットフォームのコンパイラでコンパイルされます。それはその間、約20のプラットフォームをサポートしており、32ビットと64ビットのバリエーションは含まれていません。現在、そのうちの6つが出荷されています。
C++で記述されたアドオンがあり、プロジェクトの元ヘッドがC++/MFC/Windows/x86が他のすべてのアーキテクチャとプラットフォームに取って代わると確信し始めたため、C++の作業を提供する必要がありました。スタッフを雇うことができる。彼が期待したように物事は判明しませんでした。
ドメイン言語とC++に加えて、開発者は、テストハーネスに組み込まれたインタープリターを使用して、テストケースの作成に使用されるLISPで作業します。ある時点でLISPをJavaに置き換えることを検討しましたが、そうしなかったことは幸運でした。
また、C＃で記述されたメインAPIのラッパーも備えています。これは、顧客が要求したときに行われたため、C＃でアプリケーションを書き直すことができました。これは、APIのCヘッダーファイルと重要な構成ファイルを読み取り、ラッパーのC＃コードを書き込むPerlスクリプトによって作成されます。 Perlでそのすべてのテキスト処理を行うことは、C++で行うよりも簡単でした.
ドメイン言語はmakeベースのビルドシステムに対応していないため、独自のビルドシステムがあり、それらが必要です。 UNIXライクなプラットフォーム用のものは、シェルスクリプト、Perl、およびドメイン言語のいくつかの小さなプログラムで記述されています。 Windowsプラットフォーム用のものは、バッチ言語、Perl、およびドメイン言語の同じ小さなプログラムで記述されています。古いVMSビルドシステムはDCLで作成されましたが、10年以上使用されていません。
ドメイン言語のコンパイラには、いくつかのYACC/Bisonプログラミングがあります。 AppleプラットフォームはObjective-C++で記述されています。チームの内部Webサイトの一部（プロジェクト管理に使用され、成果物の一部ではありません）はASPで記述されています。その他のコードはCGI-です。 Perlのスクリプト。
基本的に、これは難しい問題に取り組むためのプロジェクトとして始まったので、他のどのツールよりもこの仕事に適していると思われる専用ツールを作成する価値がありました。チームはプログラミングを、使用する言語からある程度独立したスキルであると見なしているので、タスクを容易にするために新しい言語を使用してもかまいません。ただし、ファッションは優先順位のリストの上位にはならないため、新しい言語を不必要に導入してタスクを細分化することはありません。
このコードの機能は、ワークステーションとサーバーで使用される数学的モデリングです（製品を特定しなければ、もう少し自由に話すことができます）。現在のLoCは約2,500万で、チームの合計サイズは約50です。
場合によっては、特定の言語から最も簡単にアクセスできる、使用する必要のあるツール（OSのUIツールキットなど）があります。たとえばiOSとmacOSで、UIKitとAppKitを使用してGUIアプリケーションを記述したい場合、SwiftまたはObjective-Cで記述するのが最も速く、最も簡単な方法です（バインディングがある場合があります）他の言語の場合は、ビルド対象の最新のOSリリースの背後にある可能性があるため、すべての機能が提供されない場合があります。
そのため、アプリケーションがクロスプラットフォームであり、アプリのコアロジックが両方にアクセスできる言語で記述され、UI/OS固有の部分がネイティブで動作する言語で記述されている場合に、多くの場合何が起こります。
したがって、WindowsおよびmacOSアプリケーションを作成している場合は、コアロジックをC++で記述し、WindowsのUIにC＃を使用し、macOSのUIにSwiftを使用できます。これにより、時間を節約できます。コアロジックを2回記述して、両方のアプリなどで異なる一連のバグに対処する必要はありません。ただし、クロスプラットフォームUIを使用するなど、プラットフォーム間の共通の最小要素に対応しない真のネイティブUIも可能になりますライブラリがします。
一部のプログラミング言語は特定のタスクに適しているという事実に加えて、実際的な現実があります。
実際には、考慮すべき2つの特に重要なポイントがあります。
- 人々はさまざまなプログラミング言語にさまざまな経験と興味のレベルを持っています。 -人々が好きな言語で作業できるようにすると、状況によっては、共通の言語に強制するよりも良い結果が得られる場合があります。
- 大規模なコードベースは、さまざまな人々によって長期間にわたって構築されています。 -適切な言語が出てきたら、プロジェクト全体を書き直すために必要な資金やボランティアの数を得る方法はありません。
そしてもちろん、アプリケーションの特定の部分には、次のようなまったく異なるニーズがあります。
- コンパイルされた言語で開発されたパフォーマンスに敏感な領域。言語の例：C++
- 安価で、変更が容易で、潜在的にカスタマイズ可能である必要がある領域は、スクリプト言語で開発されています。言語の例：Lua。
- GUIレイアウト。言語の例：HTML
- インストーラ。言語/ツールの例：WiX。
- ビルド。言語/ツールの例：列挙するには多すぎますが、通常は一度に数個です。
さらに、洗練されたコードベースで使用されるツールはかなり多く、その多くは必要なカスタマイズとプラグインをさらに別の言語で使用できます。
この質問（および回答の一部）は、アプリケーションがコードのモノリシックブロックであると想定しているようです-これは必ずしもそうではありません。
Stack Exchangeのような典型的なWebサイトは、実際には、互いに独立して実行されているさまざまなサービスの集まりであり、それらの間にはなんらかのメッセージングがあります。これらのサービスは、それぞれ独自の長所を持つさまざまな言語で実装できます（通常は実装されます）。
私は、小規模なコミュニティ銀行や信用組合を対象とした、オンラインバンキングプラットフォームのごく一部に取り組んでいます。このプラットフォームには、Webフロントエンド、データベースレイヤー、サードパーティの通信レイヤーなど、複数のコンポーネントがあります。これらはすべて、異なるオペレーティングシステムの異なるサーバーで実行される独立したアプリケーションです。ブラウザのクライアント側でJavascriptを実行している、サーバー側にPerlの構築ページがある、Perlコードと銀行のコアプロセッサ間の抽象化レイヤーとして機能するC++で記述された複数のサービスがある、C++アプリケーションの別のセットさまざまなレイヤー間でメッセージをルーティングし、C++アプリケーションとPerlスクリプトを散在させて、さまざまなプロセスの状態を監視し、それらのステータスを内部モニターなどに報告します。私のレイヤーが対話するサードパーティシステムは通常COBOLですメインフレームのどこかで実行されているアプリケーション。
モノリシックアプリケーションはまだ存在しますが、さまざまな理由で異なる言語を利用することもできます。アプリケーションの90％をJavaで作成できますが、JNIを使用してCまたはC++を活用し、よりパフォーマンスが重要なセクションを実現します。
すでに行われた他の正しい点に加えて：
経験から、多くの言語または環境の決定は「ハンマーを持っている場合、すべてが釘のように見える」ことによって行われます。つまり、人々は使い慣れたツールを使用する傾向があります。
さらに、新しい環境や言語の導入は、ライセンス、トレーニング、おそらくハードウェアへの多大な投資であり、生産時間の大幅な損失を伴います-各テイクの調達、インストール、構成、トレーニングweeks in a大企業and基本的には、初心者の開発者がたくさん集まります。
基本的に、より近代的またはより適切な環境または言語に「投資」する時間は決してないので、彼らは、それが機能しなくなるまで、自分が持っているものを使い続けます。
具体的にはあなたの質問について、複数の人/チームがソリューションの開発に参加している場合、各グループは彼らが最もよく知っていることに固執する傾向があるため、全体的なソリューションには潜在的に複数の言語があり、複数の環境での開発です。
「異なる言語には異なる強みがある」というモチーフの非常に具体的な例として、FORTRANを指摘したいと思います。
Fortranはもともと、エンジニアが数値解析作業を容易にするために開発されたものであり、Fortranコンパイラーが非常に効率的な数値コードを出力するようにするために多くの努力が費やされてきました。一方で、これらの初期の頃からコンピューターの使用は数千の方向に爆発しましたが、そのいずれも数値分析を必要としておらず、プログラミング言語の開発は「現実の」世界を無視することにほとんど追随しています[しゃれを許して]。
SO：それは今日であり、かなり広大な製品を使用している会社で働いていることがわかります。そのほとんどは（たとえば）Java （私はここでの個人的な経験から話します）。しかし、製品のコア機能の1つが何らかの形式の数値分析を提示し、その特定の分析に最適なすべてのコードがすでにFortranでネット上で利用可能であることがわかります。 ？これらのFortranコードの1つをダウンロードし、そのインターフェース（つまり、最上位のサブルーチンの引数）を理解し、そのためのJNIラッパーをCで作成し、Javaクラスとしてパッケージ化します。 BAM！一度に3つの言語で開発する必要がありました[特にFortranコードがCOMMONブロック（つまり、静的ストレージ）を使用していて、スレッドセーフのために変更する必要がある場合]
プログラミングは1つのタスクではないからです。製品を作ることさえ一つの仕事ではありません。異なる言語で最もよく表現されるタスクには複数のタイプがあります。
より具体的にするために、スタンドアロンアプリのような単純なものを想定します（分散アプリに対して実行する必要があるタスクが他にもあります）。
製品は
- 書かれた
- まとめる（これには、展開のために、画像やフォントなどのリソースのコンパイルと収集の両方が含まれます）
- 配備された
- 構成済み
- 監視
製品のランタイムを作成するのに適した言語が、製品を組み立てるのに適している可能性はほとんどありません。等々。
しかし、製品を書くプロセスでさえ、1つの言語で最適に行われるとは限りません。
製品で処理される構造化データがたくさんあるとしましょう。執筆時点でデータの構造はわかっていますか？そうである場合は、展開時にデータベースを構成する必要があります。これは、ランタイムにコンパイルされる言語を生成できる言語で最適に行われます。
次に、データの構造が時々変化する可能性がある場合はどうでしょうか？新しいデータ構造をコードとデータベース構成に変換する構造化された方法が必要です。これはさらに別の言語で行うのが最善です。
あなたはそれをすべて同じ言語で行うことができますか？承知しました。しかし、効果は、プロジェクトをどれだけ迅速に完了できるか、およびプロジェクトの変更に対する回復力によって決まります。既存のツールを使用して多くの作業を自動化できる場合、3か月かかる作業を他の人が2日間で実行できます。しかし、誰かが他の言語を使用して、あなたが繰り返し行うことを自動化するでしょう。
ソフトウェア開発は、同じプロジェクトでcan異なるプログラミング言語を使用するようになり、それを機能させることができます。
次に、質問がありますなぜ複数の言語を使用します。
その理由の1つは、言語が古くなり、新しい言語に徐々に置き換えられることです。運が良ければ、少しずつ実行できます。したがって、プロジェクトには古い言語と新しい言語が混在します。
もう1つの理由は、言語XがプラットフォームAで使用されるものであり、言語YがプラットフォームBで使用されるものであるにもかかわらず、言語Zが両方のプラットフォームでサポートされている状況です。そのため、一般的なコードは言語Zで記述され、プラットフォームに応じてXまたはYと組み合わされます。
また、他の人が作成したコード（つまり、自分で作成するために時間を費やす必要がなかったコード）を使用することを好みます。他の人が作成したコードを任意の言語で自由に使用し、好みの言語でコードを追加できます。