仕事で使うプログラミング言語はどうでもいいか？
これは、２種類の答えがあって、言語による差はないともいえるし、言語によって差があるともいえます。いや、論理的な屁理屈を言っているのではなくって、実感として。私は、職業プログラマで、今のところ普段のお仕事では業務アプリケーションのプログラミングを行う人なのですが、そういう視点からの話です。
（なんか、書いているうちに、どうでも良くなってきました。でも、せっかく書いたので。）
プログラミング言語による差はない
いわゆる、プログラミング言語の比較を行う場合は、それぞれの言語の文法的な観点から比較することを思いつく人が多いのではないかと思いますが、そういう点は、言語選択の重要な要素にはならないように思います。型のあるなしや、オブジェクト指向の書き方や、クロージャのサポートや、ブレース系かbegin end系かや、モジュール構成など、文法的な要素はいろいろあり、そういうところでプログラミング言語の好き嫌いが生まれるような気がしますが、そういうことは業務アプリケーションを書く上で、どうでも良かったりします。業務アプリケーションでは、大半の部分が、どんな言語でも大方持っている基本的な機能だけで実装できてしまうので、ほとんどのプログラマは、各プログラミング言語の特徴的な機能に依存するような書き方をする必要がなかったりします。COBOLがいまだに現役だったりするのもそういうことです。
そういう意味で、言語による差はないといえます。
プログラミング言語によって差がある
上の議論は、もっともらしく思えます。しかし、たとえば、COBOLやPerlでWindows GUIアプリケーションを作るでしょうか？ VBやDelphiでUNIXサーバー Webアプリケーションを作るでしょうか？
GUIアプリケーションなら、使いやすいGUIライブラリが備わっていて、使いやすいIDEのある言語を選択するべきです。XMLを多用するアプリケーションなら、使いやすいXMLライブラリを用意できる言語を選択するべきです。配布形態にソースコードを含めることができないならば、スクリプト言語を選択することは適切ではないですし、その上にマルチプラットフォームで実行できなければいけないならば、マルチプラットフォームで動作するWrite Once Run AnywhereなVMを持っているコンパイル済みバイトコードだけで配布可能な言語*1から選択することになります。
さらに、大規模アプリケーションの共通基盤や、レガシーシステムや外部システムとの連携部分などでは、言語に特徴的な機能によってできることできないことが決まることもあり、言語でサポートしていない機能を使うためには非常に大きな犠牲を払う必要があることも少なくありません。そういう部分に関わる人は開発チーム全体の中でもごく一部であるものの、その成果物は開発全体に関係するために、その部分の開発の品質が全体の品質に影響することもあります。
あと、これは、おまけですが、意外に重要な点が１つあります。どの言語を採用しているかは、リクルーティングに影響するということです。考慮点は３点ほどあり、その言語を読み書きできるプログラマの採用（育成）しやすさ、その言語を読み書きできるプログラマの平均的な質、その言語のもつブランドイメージ*2。しかも、開発体制によっては一度採用した言語を簡単に変更できないことも少なくないので、言語の選択による影響は数年以上にわたって持続するのです。運用・保守フェーズまで考えると、数十年にわたって、その言語との付き合いは続きます。
というわけで、あれこれ考えていくほど、プログラミング言語によって差がある側面が少なくないことに気づきます。
