『使いやすいのは動的な言語だから』というのは間違い

ruby php python java

いやー、おまいらがスクリプト言語大好きというのはよくわかった。よくわかったけど、信者はもっと落ち着いたほうがいい。

mikihoshi 「スクリプト言語の使いやすさ」のかなりの部分はスクリプト言語(動的言語)であることが担保してるんだから、「スクリプト言語並みに使いやすい静的な言語」って命題が無理筋ではなかろうか 2010/04/27

はてなブックマーク - スクリプト言語の息の根を止めるのは案外 SSD かもな - kwatchの日記

ちげーよ。動的か静的かということと、使いやすいかどうかはさほど関係ない (多少はある)。

確かに、使いやすさに定評のある Ruby や Python は動的言語で、その逆に Java は静的な言語だけど、それは Ruby や Python が使いやすさを最大限考慮して作られたが Java はそうじゃなかった (あるいは Matz や Guido のセンスは良かったけど Gosling の言語設計者としてのセンスは残念だった) というだけの話であり、動的だから使いやすいとか静的だから使いにくいというのは間違い。

現に、動的な言語だけど言語仕様が残念な PHP という言語があるし、静的だけど使いやすいと評判の Ocaml や Haskell という言語がある。まあ Haskell が使いやすいかというと個人的には疑問なんだけど、個人的な嗜好の問題なので置いておくとして、とにかく動的か静的かは使いやすさの要因にはなるだろうけど、『「スクリプト言語の使いやすさ」のかなりの部分はスクリプト言語(動的言語)であることが担保してる』というのはまったくの間違い。

しかし動的か静的かで議論になるというのは、いまだハイブリッド型な言語がまるで認知されていないという証拠なんだろう。残念。Objective-C がハイブリッドだと認知されればいいのかな。

mrkn SSD == ささだ説 2010/04/27

ブーッ！！！
1.9 が高速化したのは、SaSaDa 投入によって Ruby のボトルネックが解消されたからだったのか！
(な、なんだってー！)


追記：あわせて読みたい

スケールアウトには限界がないのか

system

cpw 2010/04/27 12:43
アプリケーションサーバは分散が容易とういうことを忘れてはいけませんよ。サーバも安くなってきてますしね。人件費の方が高コストです。

スクリプト言語の息の根を止めるのは案外 SSD かもな - kなんとかの日記

データベースサーバと違い、アプリケーションサーバはスケールアウトしやすい。今の時代、コンピュータの値段は非常に安いから、スクリプト言語の性能が低くてもマシンを買い足せばいいだけ…そういう指摘がコメントに何件かあった。これはこれで正しい。しかし、クラウドの時代だとちょっと話は違うんじゃないかとも思う。

スクリプト言語の性能が低いので、マシンを 4 台に増やしました、あるいは 10 台、20 台、…に増やしました、という程度の話なら、スケールアウトでも別にいいと思う。けど先の Facebook のようにマシン数が 3 万台とか、そこまで行かなくてもマシン数が数千台の規模になると、「マシンの台数を倍にしましょう」なんてそう簡単に言えないのではないか。10 台を倍にしても 20 台で済むけど、1 万台を倍にしたら新しいデータセンターが必要になってしまう。

性能が必要となるたびに、スケールアウトするたびに、データセンターを建てるのが本当に正しいことなのか。マシンを数台増やすだけなら「今のコンピュータは安いから」で済むけど、データセンターを建てるなら数億円の話になる。それでも「安い」と言えるのか*1。

データセンターまではいかなくとも、数百台や数千台の規模なら、ランニングコストである土地代・電気代・光熱費も相当なものだろう。マシン単体でみれば安いのかもしれないけど、ランニングコストは継続的にかかる金額だ。もっといえば電気容量や熱といった物理的な限界要因があるから、マシン台数を無制限に増やすわけにもいかないだろう。

昔、CPU は微細化が毎年進んでそのたびにクロック数が向上した。我々はそれが当たり前だと思ったし、それがいつまでも続くと無邪気に信じてた。Pentium 8 は 32.2GHz になるという予想をしたって別におかしくなかった。しかしそれは全くの間違いだったことは、今なら誰もが知っている。

スケールアウトについては我々は同じ過ちを繰り返していないと、誰が断言できようか。クラウドの時代には、今までの常識が常識でなくなり、新しい常識が生まれる。そのことは頭にいれておきたい。

*1:まあ無駄なスパコンよりはずっと安いけどな。

Facebook はなぜ HipHop を開発したかを考える

lang

もとのエントリでも触れたけど、Facebook は PHP を C++ に変換して実行する仕組みを開発し、これを HipHop for PHP という名前で公開している。

知っての通り、Facebook は世界最大の SNS であり、PHP を中心に構築されている。サーバの数も膨大で、その数約 3 万台。詳しくは Publickey の記事を参照のこと。

世界最大の SNS である Facebook が、スクリプト言語である PHP を使って構築されているという事実は、スクリプト言語でも超巨大なシステムが構築可能であることを証明している。他にも、Python なら youtuble だとか、Ruby + Rails ならクックパッドなどもよい事例となるはずだ。つまり、スクリプト言語は十分なパフォーマンスを持っている。

それでも、Facebook は HipHop を開発した。これは何を意味するかというと、Facebook は PHP のパフォーマンスに満足していないということに他ならない。今の PHP の性能で満足できるなら、あるいはシステムのボトルネックがデータベースにしかないなら、HipHop を開発しかつ実際に使用する必要はなかったはずだ。しかしそうではなかった。やはり PHP もボトルネックのひとつになっていたのだ。だからこそ、Facebook は HipHop を必要としたのだ。

あるいは、CPython の 5 倍の性能を目指すという unladen-swallow は Google の中の人が主導していることや、Google Chrome の JavaScript エンジンである V8 の高速性を考えるに、Google がスクリプト言語である Python や JavaScript のパフォーマンスに満足していないことは容易に想像できる。

個人的には現状のスクリプト言語の速度には満足しているんだけど、クラウドの時代ではそうも言ってられないのだろう。そして、今は「満足したスクリプト屋」でも、将来は「不満足な Facebook」になる可能性は、誰にだってある。

それから、

mujin script スクリプトの実行速度は問題になるほど遅くないし、問題になってもPHPならHipHopのような解決もある。開発、メンテコストも考えてよね。けっきょく同じこと言ってる。要するにタイトルで釣るなと。 2010/04/27

はてなブックマーク - スクリプト言語の息の根を止めるのは案外 SSD かもな - kwatchの日記

はてなユーザであるという立場を離れて言う。はてぶのコメントには、バカなものが本当に多すぎる。HipHop についてもちゃんと紹介しているエントリーに対して、どうして『HipHopのような解決策もある』という意見を書く気が起きるのだろう。

　・
　・
　・

疲れたね。長文乙。もし今年の RubyKaigi に応募してなかったら、それは締め切り直前にこんなクソ長いブログを書いていたせいで応募できなかったからだと思ってくれて結構。