ひとつの言語に依らないシステム

OneLanguage - Martin Fowler's Bliki
ひとつの言語 - Martin Fowler's Bliki in Japanese(ぶりきじゃ)

複数の言語を一つのシステムで使うことが別に驚くことではなくなったのは、少し前から実感している。

C/S(クライアント・サーバ)時代はインタフェースもロジックも一つのプラットホームと言語で開発することが当たり前であったが、ここ数年はLinuxの台頭と共に安価で安定したサーバを構築できるようになり、Webサーバベースのシステムが普通の案件の提案に乗るようになってこの図式は必ずしも守られなくなった。サーバはオープンソースで固めることが出来るが、クライアントは相変わらずWindowsが殆どの状態であり、Webブラウザをクライアントに使うシステムではそのまま、又はよりリッチなユーザインタフェースを求めるシステムはWebブラウザのインタフェースをスクリプト又はアドオンで拡張するか、従来から使っているWindowsのGUIをWebサーバベースのシステムでも活用するかの二極に分かれつつある。

両者ともサーバは一般のWebサーバでよくプラットホームは選ばないというのが特徴であり、ロジックはサーバ上に配置する。そうなるとロジックを書くための言語はJava、Perl、Ruby、PHP、Python、等なんでも良くなる。 (対してクライアントはHTTPが話せればよい)
このシステムの最大のメリットは細々したことを抜きにしてサーバプラットホーム、データベース(及び開発言語)を顧客側が自由に選択できることと、クライアント側にやっかいものだったデータ層のミドルウェアを必要としないことだ。
ユーザインタフェースはお好みで(システムのインタフェースの要件に合わせて)決めれば良い。それによりおのずとクライアント側のプラットホームと言語も決まる。(開発言語がマークアップだけの場合もある)

実際の例で言うと最近見た仕事ではサーバサイドにJava(一部はシェル)、クライアントにVB.NET(一部C#)という構成だった。最初、顧客は複数の開発言語が必要な事を知ると嫌な顔をしたが(後で聞いたことだが技術者の調達を懸念したらしい)、実際に開発が進んでいくにつれ、何も言わなくなった。実の所、ちゃんとしたエンジニアであれば言語はあまり関係無いのだ。(CとC++だけは別だ。使いどころを間違えないようにしたい)

余談だが、マルチティア/マルチプラットホームのWebベースのシステムがデファクトとなって何が嬉しいって、CORBAを使わなくて良いことだろうと思う開発者は多いだろう。