プログラミング言語の燃費

サーバー屋さんはPerlを嫌っていて、C言語でアプリを書いてほしがっているけど、それに違和感を感じると言う話。

ある程度の規模以上のWebアプリケーションは、個人がCでゼロから書けるものではありません。言語、ライブラリ、フレームワーク等の様々な資産の上に乗っかることで、以前では考えられないような開発効率を実現しているのです。

上の引用はちょっとひっかかるものがあります。なぜ裸のC言語と、ライブラリ付きのPerlPHPを比べるのでしょうか。それはフェアではありません。
C/C++にライブラリ環境が整っていれば、きっとPerlに比べて気の遠くなるような作業というわけではないでしょう。裸のPerlだって、ゼロから大規模アプリを個人で書けるわけではないでしょう。
PerlRuby, PHPには膨大なライブラリ、フレームワークがあるという事かもしれませんが、だったら、C言語にも誰かが作ればよいわけですよね。そもそもリンク先が引用している批判はインタープリター言語への批判であって、Perlへの個別批判ではない気がします。
データセンターでの体積あたり発熱量が問題になって久しいですが、IntelAMDの努力で大幅に改善されました。それでも、体積あたりのWEBサービス密度のボトルネックが熱であるのなら*1、低発熱アプリケーションが求められるのは必然だと感じます。
需要があって供給がないところに供給するのが資本主義の基本です。データセンターが満足する効率のPerl/PHP/RubyJITコンパイラを供給すれば、あるいはプログラマが満足するC++フレームワークを供給すればいい商売になると思うのですが。
「だって使いにくいもん」と言ってるだけでは取り残される気がします。
外野から組み込み屋*2による放言でした。

ところで

ローカルなマシンのプログラム開発はコンパイラ言語、JIT言語が主流なのに、サーバサイドがインタープリター言語*3のまま止まっているように思えるのはなぜでしょうか。JAVA, C#のような企業開発言語はJITコンパイラが広く使われていて、Perl,PHP,Rubyのようなコミュニティ開発言語ではインタープリターが主流だとしたら、それはそれでなかなかに面白いです。
この辺全然知らないからほんと外野だなぁ。

*1:仮定です。ほんとうはどうなのか、私は知りません。

*2:しかもアマチュア開発者

*3:JITコンパイラもあるけど

/* -----codeの行番号----- */