単一言語

開発作業において、単一の言語のみを使用するように努力すべきでしょうか？

過去10年間の大部分において、エンタープライズソフトウェアの世界では、ソフトウェア開発 efforts において1つの標準言語に焦点を当てることが流行していました。多くの開発組織は、すべての作業をJava（またはC＃/ VB）で行うように努めています。

この根拠は、開発者は複数の言語に精通するのが難しいということです。単一の言語に固執することで、特に新しい人を雇う場合、学習負担が軽減されます。

これにはある程度の真実がありますが、欠けているものも多いです。プログラミング環境は、部分的には言語ですが、言語とフレームワークについてもです。大規模なフレームワークであるHibernate、Struts、ADOは、単一のホスト言語でプログラミングする場合でも、言語を学ぶのと同じくらい難しい課題となります。多くの場合、ホスト言語で必要なものを表現することの難しさは非常に厄介であるため、多くのフレームワークは設定ファイルに頼っています。設定ファイルは、事実上、XMLで記述された外部ドメイン特化言語であり、80プルーフの醜さを追加します。

多くの開発者にとって、単一言語の概念はプロ意識の欠如の表れです。これは、Pragmatic Programmers'が毎年新しい言語を学ぶというアドバイスによって最もよく例示されています。ここでのポイントは、プログラミング言語はプログラミングに対する考え方を変えるものであり、新しい言語を学ぶことは、問題をさまざまな方法で解決することを考えるのに大いに役立つということです。（このメリットを得るには、まったく異なる言語を学ぶことが重要です。JavaとC＃は、カウントするにはあまりにも似ています。）

ほとんどのことと同様に、私はpragsのアドバイスに同意します。しかし、私は新しい言語を学ぶことのオーバーヘッドにも共感します。私の個人的なスクリプトはほとんどすべてRubyで書かれており、Python、Groovy、PowerShellなどの合理的な代替案を試してみることを嫌っていました。代替案を使用するのが難しいというわけではありませんが、Rubyでは、代替案で調べなければならないことをたくさん知っています。

ここでの重要な点は、これらのスクリプトを作成するとき、私は新しい抽象概念を操作していないということです。私が行うことの多くは、テキスト、ファイルシステム、XMLまたはYAMLの塊をいじることです。かなりの新しい抽象化を取り入れる必要がある場合、ライブラリとして学習するコストは、それを操作するために言語を学習するコストとそれほど変わりません。表示のために有向グラフ構造を指定したい場合、Graphvizの Dot言語を学ぶことは、新しいRubyライブラリを学ぶこととほとんど変わりません。

ライブラリの代わりにDSLを使用すると、抽象化をより適切に操作する方法が提供されます。これにより、書いた内容が見やすくなり、意図が明らかになります。APIは語彙を宣言するようなものであり、DSLは首尾一貫した文を書くことができる文法を追加します。

この議論はDSLには強力ですが、汎用言語にも当てはまりますか？Java（またはすぐにC＃）で作業している場合、プラットフォームで利用できるようになったRubyを使用することは理にかなっていますか？

過去10年間で、メモリ管理されたCベースの言語が台頭しました。人々は、長年の懐疑主義にもかかわらず、メモリ管理は人生を十分に良くし、エンタープライズの世界ではCとC ++から離れる価値があると見ました。共通のプラットフォームと言語も、PowerbuilderやDelphiのような独自の壁に囲まれた庭から人々を引き離しました。

今度は同様の質問があります。最新のスクリプト言語は、さらに一歩前進したものでしょうか？私たちは彼らのよく選ばれた簡潔さを好みますか？経験豊富なJavaおよびC＃開発者がRubyでより効果的であると報告しているのを何度も耳にします。そのため、Rubyを推奨してきました。今後数年間で他の言語についても同様の報告書が表示されても、私は驚かないでしょう。

10年前、私はOOPSLA 96で旧友のトム・ハドフィールドと話していました。Javaの台頭は明らかであり、Smalltalkの未来は運命づけられていることは明らかでした。Smalltalkへの愛情にもかかわらず、私はかなり楽観的でした。Javaは人々に必要なものを十分に提供していると感じました。Smalltalkほど良くはありませんでしたが、特にメモリ管理に関しては、C ++よりも十分に改善されており、満足できるものでした。トムは同意しませんでした。彼は、Smalltalkの表現力、コードで直接行っていることの意図をよりよく捉える方法に、根本的に異なる何かがあると feltました。ドメイン知識とプログラミングのギャップを埋めました。

interveningの間に、私はトムが結局正しいという見解に至りました。中括弧の土地で数年過ごした後、Rubyは私が何を見逃していたかを思い出させてくれました。Rubyコードを読むことには明瞭さがあり、ツールが劣っているにもかかわらず、作業しやすい媒体になっています。私は、長い間怒りでイメージを開こうとは思っていませんが、Smalltalkの holdoutsに、当時よりも共感しています。

では、80年代後半から90年代初頭の言語の不協和音に戻っているのでしょうか？複数の言語が blatheringしているのを見ると思いますが、重要な違いがあります。80年代後半には、言語を緊密に相互運用させるのは困難でした。最近では、異なる言語が緊密に共存できる環境を作ることに多くの注目が集まっています。スクリプト言語は伝統的にCと緊密な関係を持っていました。JVMおよびCLRプラットフォームでの相互運用には多くの effort があります。言語が無視するには、ライブラリに投資が多すぎます。

ですから、私の感覚では、人々が現在フレームワークを選択するのと同じように、人々が何ができるかによって言語を選択することで、プロジェクトで使用される複数の言語が見られると思います。私はNealに同意します。私たちは多言語プログラミングの時代に入っています。