挑発的なタイトルによって誰かが気分を害してしまう前に、私はこの問いに対する答えも書いてしまうことにしました。答えは“ノー”です。しかしこのテーマには、なかなか興味深い議論があるのです。HaskellやErlangや、特にClojureなどのあら探しをするつもりはないのでしょうが、Piaw NaはQ&AサイトQuoraの あるアンサー で以下のようにコメントしています。

プログラミング言語を固定するのは二流のエンジニア／コンピュータサイエンティストである証です。

[中略]

私がErlangのサーバに携わるポジションの採用をした時も、Erlangのスペシャリストだと言うエンジニアより、優秀なオールラウンダーのエンジニアを雇ってErlang（これに限らず何でも）を学ばせてそのポジションを埋める方が断然いいと感じました。

Na氏の意見は1990年代に設立されたGoogleやAmazonなどの技術系企業の間で主流となった考え方と似ています。当時プログラミング言語の研究は廃れた無用な分野であると考えられていたのです。大規模なアプリケーションはC++もしくはJavaで記述されていました。10～20年前は、Pythonが最先端でリスキーなものとされ、LispやHaskellなどの言語は全くと言っていいほど使われていませんでした。Paul Grahamは賞賛に値する人物です。スタートアップでLispの使用を決めたことだけでなく、Lispや表現力に富む言語（Pythonなど）全般を彼の雄弁さで擁護したことも、高く評価できる点です。以下は彼のエッセイ 『Pythonのパラドックス』 からの抜粋です（太字は全て私が加えたものです）。

最近の講演の中で、私は多くの人を怒らせるような発言をしてしまった。Javaを扱うプロジェクトよりもPythonを扱うプロジェクトの方が賢いプログラマを集められると言ったのだ。

Javaのプログラマがバカだと言いたかったのではない。Pythonのプログラマが賢いということなのだ。新たなプログラミング言語を学ぶには、やらなければならないことが山ほどある。Pythonを学ぶ人は、それで職を得ようとして学ぶのではない。本当にプログラミングが好きで、既に知っている言語では満足できないから学ぶのだ。

その気持ちが、彼らを企業が雇いたいと思うプログラマにさせるのだ。そこで、もっといい名前があるかもしれないが、私は以下の論理を「Pythonのパラドックス」と呼ぶことにする。比較的難解な言語でソフトウェアを記述しようとする企業は、より良いプログラマを採用することができるだろう。学ぶことに意欲的な人材だけが、その企業を魅力的だと感じるからだ。そしてプログラマには、このパラドックスはさらに顕著に現れるだろう。職を得たいと思った時に学ぶべき言語は、普通の人が単に仕事を得るだけのために学ぼうとは思わないような言語だということだ。

この2人の意見は必ずしも矛盾しているというわけではなく、提唱している採用戦略が異なるということです。Piaw Naは、自分がClojureやHaskellのエンジニアだと強く主張してくる人に対して、もっと疑いの目を持った方がいいと言います。一方Paul Grahamは、あいまいな人よりも自分が賭ける言語について強い意見を持つプログラマを選ぶべきだと言います。

ではどちらが正しいのでしょうか？　言うまでもなく、両者ともそれなりに正しいのです。そうでなければこのエッセイは面白くなりませんからね。

プログラミング言語は優秀なソフトウェアエンジニアにとっては重要なものです。 Macarena が流行した頃から、多くのソフトウェア会社の管理職や“アーキテクト”の間に「言語は問題ではない」とする風潮が出てきました。このように言うのは1行のコードも書いたことがないような人たちです。今も実際にコードを書いている人たちは、自分の使うツールのことをとても気にかけています。しかし、Piaw Naの意見の、一言語しか使わないプログラマは凡人であることが多いという点は正しいでしょう。優れたエンジニアはそれぞれの仕事に適したツールを使いたいと考えますが、全ての仕事に合うツールなどプログラミング言語の世界にはないのですから（むしろそれには程遠いです）。

それがJavaであろうと、おそらくもっと優れたHaskellやErlangであろうと、コンフォートゾーンを外れた部分の勉強を嫌がるようなプログラマはだいたい二流でしょう。どんなプログラミングのタスクでも、どの言語でも一定の達成をすることはできますが（チューリング完全）、実用面での性能における言語の変化は非常に速いものです。全ての言語に圧倒的に勝るたった1つの言語など存在しません。プログラミングには多様性があるからです。いくつかのアルゴリズムは、手動でメモリ制御しなくては効率的に記述するのは不可能に近いです。Cのような言語を使うしかありません。絶対に失敗できない通常の本番サーバなら、おそらくHaskellが最も有力な選択肢でしょう。対話環境なら、Clojureのファーストクラスの“repl”（対話型コンソール）に勝るものはなかなかありません。

私はJavaのことを多少（もしかしたら相当）悪く言ってきました。それは私が “Java 屋” の文化がすごく嫌いだからです。巨大なXMLファイル、AbstractFactoryManagerSingletonFactoryパターン、IDEに依存したビルド・・・こういうナンセンスなものは全て業火で焼き尽くされてしまえばいいと思っています。Java業界のセンスのなさには驚きです。個性のないひどいコードが生み出されては、あっという間にダメになっています。それを保守しようというちゃんとしたエンジニアがいないからです。Java業界の単一言語思想が、こうした文化の問題につながっているのでしょう。やる気のない開発者や目先のことしか考えない無能な管理職を抱え、問題に対し十分なエンジニアを投じなければ基本的な働きもできない言語がそこにある時、Java以外のものを使わない理由はまずないでしょう。

二流のJava開発者に顕著な特徴は（これはきっと.NETや、多分C++でさえも同様なのですが）、プログラミングについての考えが「Javaで何ができるのか」という所で止まってしまっているということです。上司が彼らに他の言語を使わせようとしないせいで、Java以外の言語など学ぶ必要はないと思ってしまうわけです。彼らにアセンブラやOSの仕組みについて尋ねてみてください。きっとポカンとした顔をされるでしょう。彼らに機械学習やコンピュータグラフィックスについて聞いてみてください。朝8時の線形代数学の授業がどのようなものだったか、ぶつぶつ言う声が聞こえてくるでしょう。彼らはプログラムの書き方を忘れてしまっているし、大学以来ひとつもプログラムを動かしていないのです。代わりにただ一日中クラスを作り続けて、そしてそれらをホッチキス留めして何かを作り出すのが“ちょっとできる男”（この“ちょっとできる男”が“あなたのJava”、つまりIDEが壊れた時に直してくれるのです）の仕事だということになってしまうわけです。企業プログラマの文化がソフトウェアエンジニアリングをここまで堕落させたのです。そしてその結果、いくら彼らが“ユーザストーリー”の書き方や“バックログ”の手入れや裏工作に精通しているとしても、CommodityJavaDrones は長年にわたり実際的なコンピュータサイエンスには程遠いものになっているのです。

これはJava自体の過ちではありません。この言語には欠点もありますが、ビジネスがもたらす愚かな事態は1995年には現れていませんでしたし、Javaが登場しなければ他の言語で同じ事が起きていたことでしょう。James GoslingがJavaを開発した時にはAbstractFactoryVibratorSingletonsのようなものは意図していなかったはずです。彼はJVMのための（C言語のような）純粋な低級言語を望んでいたのです。彼が解決しようとした問題に対しては、Javaはきちんと役に立ったのです。

コンフォートゾーンは負け犬のためのもの

Piaw Naの言っている事は正しく、（ErlangやHaskellのような）より興味深い言語を使うプログラマが皆、一流というわけではありません。悪いコードやいい加減な技術は全ての言語に見られます。時として幸運に恵まれた初心者が、初めての仕事で深みのある言語に携わることがあるかもしれませんが、やはり成長はできないでしょう。滅多にないことですが、そういう事態が起こるのを見たことがあります。

この業界ではまともであろうとする人がコンフォートゾーンを手に入れることはできません。「静的型付き言語は絶対に使わない」とか、「低級言語はやらない」とか、「Javascriptは醜いからブラウザには近寄らない」とか、あるいは「自分はOSを一生理解できない」といったような態度に固執しているような人は、一流のプログラマにはなれないでしょう。これは逆説的であり、難しいことです。なぜなら学習を継続しエキスパートで居続けるためには、自分が何に取り組むのかについて極めて選択的でもいなければならないからです。その一方でコンピュータサイエンスのいかなる領域も無視するわけにはいかないのです（“ストーリーポイント”のようないんちきプロセスは脳を腐らせるだけなので無視してかまいませんが）。

好奇心旺盛な人であれば、ただ難しいからというだけの理由で、あるコンピュータサイエンスの領域を無視したりはしないでしょう。物事は極めて頻繁に変化します。当然、好みを持つのは結構なことですし、避けられないことではありますが、好みは私が問題視している障壁を作り出してしまいます。もちろん私たちは何かを始める時には必要に迫られて障壁を作り出し、集中すべきものを選択しなければならないのですが（広く浅くになってはいけませんから）、私が言いたいのは、より良いコンピュータサイエンティストというのはそうすべき理由があれば、この障壁を崩すことをいとわない人だということです。コンピュータサイエンスに正しく取り組んでいる人にとって、全ての問題は新しいものであるべきで、見返りや複雑さややりがいの点において進歩していくべきものでしょう。そして解決した問題が反復的なものであれば、極力自動化されるべきでしょう。

Paul Grahamは“Blub”という概念を取り入れることで、ひとつの言語をコンフォートゾーンとして使うことの危険性について警告しています。Blubはひとつの言語しか使わない企業プログラマがあらゆる形のプログラミングにモデルとして用いる典型的な二流言語です。Blubプログラマは低級言語を役立たずな間抜けと見なし、高級言語は抽象的で気味の悪いだけのものだと思っています。もちろんBlubは現実の言語ではなく、態度のことを表す仮想の言語です。Javaはおそらく、少なくとも企業で使う言語の中では、Blub中のBlubです。とはいえ誰かがHaskellを自分の個人的なBlubだと考えるのを止めることはできないのですが。

さて何がJavaをこのような一般的なBlubにしてしまったのでしょう？　私はその一因は、この言語が多くのことをそれなりにこなしてしまう、ということではないかと考えています。もし一言語プログラマを目指すなら（あるいはもっと悪いことに“$LANG Shop”な一言語企業を目指すなら）、Javaは悪い選択ではないのです。覚えるのは難しくないですし、結構いいコードを書くことができますし、ライブラリのサポートは強力です。並レベルのエンジニアの視点から見てみましょう。なぜなら優れたエンジニアはほとんどが間違いなく多言語使用者ですし、レベルの低すぎるエンジニアは言語やソフトウェアエンジニアリングなど気にしないからです。ビジネス主導のエンジニアの職場では、並レベルのエンジニアはリーダーとして浮上していきますから、並レベルでいることの優位というのも便利なものなのです。Pythonの並レベルのエンジニアなら、いくつかのルーチンはC言語で書く必要がある、とすぐに気付くでしょう。普通、Pythonは処理速度が遅いからです (ダメなエンジニアはパフォーマンスのことは考えないし気にもかけません。彼らにとっては数学のおまじないのようなものです)。必ずしもC言語が得意でないとしても、また特に使用するのが楽しくなくても、彼らはC言語を考慮の対象から除外したりはしません。一方でJavaの並のエンジニアはC言語とは何かということすら、気に留めることもないでしょう。
Blub言語に関して言えば(言語の基礎の部分は)Javaも、そう悪くはありません。PHP、Javascript、Visual Basicよりはマシです。しかし文化的な側面から中毒性のあるBlub語になりがちです。Na氏が指摘するのは、Erlang以外のコードを拒否するような人はおそらく一級の開発者ではないという点です。まさにその通りだと思います。私はHaskellが大好きなので、私に決定権がある場合ほとんどのプロジェクトにHaskellを選ぶでしょう。でもClojureやC言語、Python（データサイエンスのライブラリ向け）やScalaも経験してきました。コンフォートゾーンというのは二流プログラマのサインだと確かに思いますが、もっと言えば、CommodityJavaDronesは大抵の場合三流です。自分のコンフォートゾーンにしがみつくよりも悲惨なのは、他人のコンフォートゾーンに安住することです。

ビジネス主導のエンジニアリング（または下水のウォーターフォール）

余談ですが、一流のエンジニアがプログラム言語に関してそれほど固執していないように見える理由のひとつは、彼らが技術的判断を任されることが多いからです（もしそうでない場合は会社が正当な評価をしていないので、辞めるべきでしょう）。もし、あなたがまだ経験が浅く、影響力も小さいなら、最終的に“Java屋”に落ち着くか、“Python屋”に落ち着くのか気になるでしょう。その言語以外は使えなくなるからです。あなたがベテランで強い影響力を持っているなら、新しいプロジェクトに関わる機会も多くなり、自分でツールを選べるでしょう。優秀なエンジニアであれば、ビジネス主導のエンジニアリングとお仕着せの業務を絶対に避けるものです。もちろん最初から一流のエンジニアだった人はいませんから、“優れたエンジニアになる”前の段階にある人は、そのようなサインに注意して会社を選ばなくてはなりません。もし、その会社が“Java屋”だとしたら、それは非常に悪い兆候と捉えるべきです。
Javaは私のお気に入りの言語ではありませんし、使用言語は重要ではないという（ウソの）主張には賛成しません。それでも、Javaが適している状況もあり得ます。もしJVMを使う必要があり、ClojureやScalaに人件費（小さいけれどゼロではない）が割けない場合、Javaが適当な選択でしょう。前述したように、Javaの醜さというのはそのすべてが言語固有な問題というわけではなく、Java業界のアンチ知性的な文化によるところが大きいのです。
プログラミングという仕事について回る悲惨さを今まで避けて通って来た人は、ラッキーです。ソフトウェア開発会社の多くは、こんな風に仕事をしています。つまり、ビジネスありきでアイディアが生み出され、仕事を定義し、プロダクトマネージャが間に介在して延々と会議に時間を費やし、プログラマはただ実装するだけです。ほとんどの 「スクラム開発のチーム」 はただのチケット屋です。エンジニアに自治はありません。これがビジネス先導型のエンジニアリングです。私はこれを「下水のウォーターフォール型エンジニアリング」と呼んでいます。「ウォーターフォール型」を非難することにより、私があたかも「アジャイル」を支持しているように思われるかもしれませんが、それは違います。「アジャイル」の問題点は、それがやはり、お仕着せの業務でありビジネス主導のエンジニアリングだからです。何も成し遂げてはいないということです。ビジネス主導型エンジニアリングを“修正して使おう”とする努力は、まるでクソの上に塩をふりかけて食べられるようにしようとするようなものです。土台、無理な話なのです。
矛盾して聞こえるかもしれませんが、エンジニア主導の会社は、より良い技術とビジネス成果を得ることができます。ビジネス主導型のエンジニアリングは精神を腐らせます。創造的かつ挑戦的な自制心であるべきものが「7つのクラスと17+i のストーリーポイントを金曜日までに書け」ということに置き換えられてしまうからです。テクノロジーの世界において年齢差別の問題があるのも、ここに一因があります。このようなくだらないことをして20代を過ごせば、30歳までには実際お偉方のように（ぼけた頭になってしまうという意味において。必ずしも地位と給与が伴うとは限りません、悪しからず）なってしまうでしょう。

Javaを使う人で優秀なエンジニアはいるのでしょうか。もちろんです。Haskellコミュニティの中であまり大したことのないプログラマはいるのでしょうか。いますとも。でももし底辺の、 プログラムもろくに書かないプログラマ と本当に出会う気があるのなら、ビジネス主導型エンジニアリングの糞尿地獄に行って見てください。

賭けごとなどに関して

雇用とは大体において、最も勝算の高そうなところに賭けることです。Haskellが使えるという条件で優秀なプログラマの採用が保証されるわけではありません。Piaw Naが言っているように、才能あるプログラマをHaskell経験がないという理由で採用対象から除外すべきではありません。優れた技術者は新しい言語を短期間で習得することができるからです（平均的なJava業界のコードベースは概して冗長で低品質なことが多いため、そっちを習得するほうが、HaskellやClojureを習得するよりも時間がかかります）。ただ、実りの多い採用をしたいと思う時、HaskellやClojureのような言語を使えるという条件が勝算を上げるかという質問には、もちろんと答えます。それらの言語が扱える(大抵は)優れた開発者を雇用できるだけでなく、優れたコミュニティへのアクセスを得ることができるからです。

これも言っておきますが、私の知るHaskellとClojureのエンジニアのほとんどは、自分のコンフォートゾーンにしがみつくような単一言語使用者ではありません。カンファレンスや講演でこそ、これらの“エリート”言語について時間を割きますが、他言語や他のパラダイム（論理プログラミングとかアセンブリハッキングだとかに関わらず）からアイディアを得た発表も多くあります。これらの言語とコミュニティを差別化し、何か特別なものにしている要因は、そこに二流のエンジニアがいないということではありません。平均的なエンジニアがとても有能だからです。だからこそ活力が生まれ、友好な競争の感覚が生まれるのです。こういうことはJava屋の企業には見られません。

Python のパラドックスに従っても、必ずしもいい人材が採用できるとは保証できません。結局のところ良い人材は、良い雇用体制があってこそ採用できるのです。でも「使用言語は重要なのか」という議論において、どちら側の勝算が高いのかは、とても明白であるように思います。