ポリグロット、または多言語のソリューションを使用すると、言語を最も適した問題に適用できます。それでも、少なくとも私の経験では、ソフトウェアショップは、解決しようとしている問題のすべての側面に「スーパー」言語を適用したいと思う傾向があります。問題を簡単かつ自然に解決する別の言語が利用可能であっても、その言語に固執することは「地獄または高水」になります。ポリグロットソリューションを使用して実装するのはなぜですか、または実装しないのですか?
6 に答える
私はほとんどの場合、ソリューション空間で複数の言語を推奨しています (実際には、SQL は非常に多くのプロジェクトの一部であるため、2 つ以上です)。クライアントが明示的な型付けと豊富な人材を備えた言語を好む場合でも、管理、テスト、データ スクラビングなどにスクリプト言語を使用することをお勧めします。
多言語の利点は、「仕事に適したツール」に集約されます。
ただし、正当な欠点があります。
- コードの共同所有権を持つのが難しい (全員がすべての言語に精通しているわけではない)
- 統合の問題 (マネージド プラットフォームでは減少)
- インフラストラクチャ ライブラリからのランタイム オーバーヘッドの増加 (これは多くの場合重要です)
- ツールのコストの増加 (IDE、分析ツールなど)
- あるものから別のものに切り替えるときの認知的な「隆起」。これはもろ刃の剣です: 熟知した人にとっては、異なるパラダイムは補完的であり、1 つのパラダイムで問題が発生すると、「しかし XI では Z でこれを解決するだろう!」ということがよくあります。そして問題は迅速に解決されます。ただし、パラダイムをよく理解していない人にとっては、「これは何だろう?」と理解しようとすると、実際に速度が低下する可能性があります。
また、多くの言語を使用する場合は、アプローチが大きく異なる言語を使用する必要があると言うべきだと思います。たとえば、プロジェクトで C# と VB の両方を使用しても、問題解決の点で多くのメリットがあるとは思いません。主流の言語に加えて、スクリプト言語 (小規模で 1 回限りのタスクの生産性が高い) と、認識スタイルが大きく異なる言語 (Haskell、Prolog、Lisp など) が必要になると思います。
私の雇用主の態度は、常に有効なものを使用することでした.
これは、いくつかの有用なPerl
モジュール (「ベンフォードの法則」を実装するモジュールなど)を見つけたときにStatistics::Benford
、ActiveState の の使用方法を学ばなければならなかったことを意味しますPDK
。
GNAT
プロジェクトに区間演算を追加することにしたとき、私は Ada ととの両方の使い方を学ばなければなりませんでしたObjectAda
。
高速な文字列ライブラリを求められたとき、アセンブラを学び直し、 と に慣れる必要がMASM32
ありWinAsm
ました。
libiconv
(Delphi Inspiration のコードに基づく)の COM DLL が必要になったとき、私はDelphi
.
Dr. Bill Poser の を使いたいと思ったとき、 と6 の IDE の使い方libuninum
を学び直さなければなりませんでした。C
Visual C++
彼らはそれが得意なので、私たちはまだVB6
とでプロトタイプを作成しています。VBScript
いつかは、Forth、Eiffel、D、または Haskell で何かをすることになるかもしれません (言語自体に反対するものは何もありません。それは非常に異なるパラダイムです)。
私は幸運にも、自分の仕事に適した言語を提案してくれる小さなプロジェクトに携わることができました。たとえば、低レベル言語としての C は、高レベル/プロトタイピング用に Lua を拡張することで非常にうまく機能し、新しい組み込みプラットフォームですぐに使いこなせるようになりました。私は常に、より大きなプロジェクトには 2 つの言語を使用し、その特定のプロジェクトにドメイン固有の言語を 1 つ使用することを好みます。新しい機能をすばやく試すための多くの表現力が追加されます。
しかし、おそらくこれはアジャイルな開発方法に最も役立ちますが、より伝統的なプロジェクトの場合、最初に乗り越えなければならないハードルは、使用する言語を選択することです.画像。
多言語ソリューションの最大の問題は、関係する言語が増えるほど、適切なスキル セットを持つプログラマーを見つけるのが難しくなることです。特に、言語のいずれかが少しでも難解であるか、まったく異なるデザインの流派から来ている場合 (たとえば、関数型、手続き型、オブジェクト指向など)。はい、優れたプログラマーは必要なことを学ぶことができるはずですが、経営陣は、それがどれほど非現実的であっても、「すぐに実行できる」人を求めていることがよくあります。
その他の理由としては、コードの再利用、異なる言語間のインターフェイスの複雑さの増大、特定のコードが属する言語をめぐる避けられない縄張り争いなどがあります。
そうは言っても、多くのシステムは設計上多言語であることを認識してください。データベースを使用するものはすべて、他の言語に加えて SQL を使用します。また、実際のコードまたはビルド システムのいずれかで、スクリプトも必要になることがよくあります。
私のプロとしてのプログラミング経験のほとんどは、上記のカテゴリに属しています。一般に、コア言語 (C または C++)、さまざまな程度の SQL、シェル スクリプト、および場合によっては周辺にいくつかの perl または python コードがあります。
私が遭遇した問題の1つは、Visual Studioでは1つのプロジェクトに複数の言語を混在させることができないため、言語ごとに別々のDLLに抽象化する必要があることです。これは、必ずしも理想的ではありません。
ただし、主な理由は、多くの異なる言語間を行ったり来たりすると、プログラマーの非効率性につながるという認識にあると思います。これにはいくつかの真実があります。私はJavaScript、C#、VBScript、およびVB.NETを絶えず切り替えています。構文を少し混ぜると、ある言語から別の言語に切り替えるときに少し時間が失われます。
それでも、特にJavaScriptやバックエンドプログラミング言語の使用を超えた、より多くの「ポリグロット」ソリューションの余地は確かにあります。