Re: スクリプト言語の息の根を止めるのは案外 SSD かもな

flat8 2010/04/27 10:19
確実にIntelはそこまで考えていると思います。で、ある程度SSDが普及したらSSD自体の製造からは手を引くでしょうけど。

やはりそうでしょうか。さすがIntel。
ところでIntelが『SSD自体の製造からは手を引くでしょう』という根拠は何でしょうか。CPU ほどは儲からないからかもしれませんが、減価償却の終わった製造施設で生産できるなら、Intel としては悪くない分野だと思うので、製造は続けていくように思います。

通りすがり 2010/04/27 11:31
クライアントコードの処理時間（コスト）：バックエンドの処理時間（コスト）の考察無しには、SSD時代になったとしても一概にスクリプト言語不利とも言えないのではないでしょうか。

SSDによりディスクI/Oのボトルネックが大きく軽減されることは、スクリプト言語にとって不利になるのは間違いないと思います。あとはそれがどのくらい不利かが問題。さほどの不利ではないという考えも当然できますが、それは人によって判断が異なるでしょう。

yuki_hero 2010/04/27 12:10
まぁ、巨大な企業は、社会基盤そのものにも目をつけていますから...

目をつけられない頭の悪い企業も多いですけどね。特に日本は。

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

『アプリケーションサーバは分散が容易』ですが、数千台・数万台という規模になると、さすがにそうもいってられないでしょう。サーバ自体は安くても土地代や電気代や光熱費はばかにできませんし、もし仮にですがスクリプト言語を止めることでサーバ台数が 1 ケタ減らせるぐらいの効果があれば、さすがにスクリプト言語は使わないと思いますよ。あくまで仮定の話ですが。
あと『人件費の方が高コスト』というのはその通りですが、今の話とどう関係が？スクリプト言語のほうが人件費を削減できるとでも？

Goat 2010/04/27 13:02
ボトルネックになるのはストレージだけではないでしょう。PHPはもちろん、Ruby、Python、Perlも多くはウェブ系のシステムに使われていると思いますが、そういう場合ではネットワークがボトルネックになってきます。
そして、スケールアップよりもスケールアウトという流れの中でますますその傾向は強くなっています。
仮にコードがボトルネックになったとしても、多くの場合はアルゴリズムに問題があるのであって、そこを改善してオーダーを変えてしまえば、5倍〜10倍の差なんて問題にならなくなりますし、そもそもタイムクリティカルなミドルウェアでは今でもCやC++が主流なのでSSDがスクリプト言語に与える影響はほとんどないのではないかと思います。

はい、ボトルネックはストレージだけではありません。しかしストレージ以外のボトルネックも将来は解消される可能性が十分あり、そのときに備えて手は打っておくべきだと思います。
あと『多くの場合はアルゴリズムに問題がある』というのは本当に実感します。これについては別途エントリを書きます。

通りすがり 2010/04/27 13:44
インタプリタかコンパイルかで速度が極端にかわるようなら、単純にPerl,PHP,Ruby,Python等で静的コンパイルできるようにするんじゃないかなぁ〜？

インタプリタ型言語も内部的にはコンパイルしてから実行してますし、さすがにこのコメントは的外れでしょう。

muha 2010/04/27 13:51
逆にますますインタプリタが使われると思う。　人件費より高いの無いでしょ

んー、インタプリタだと人件費が抑制できるという主張でしょうか。その根拠は？Java開発者よりPHP開発者のほうが単価が安いということ？

とことこ 2010/04/27 14:38
確かにトランザクションが多いところはそうなるかもしれない、
よく知りませんがスクリプト言語の作成効率が高ければ、そんなにトランザクションがおきないところは安く構築するために有効だと思われるので、そんな劇的にシフトはしない気がする。

これも「スクリプト言語のほうが安く済む」という前提のコメントですね。その根拠って何でしょうか。

Taruryun 2010/04/27 17:08
元のテストの結果は、僕が読む限り、
処理能力が頭うったのは
『ＤＢサーバの』ＣＰＵに読めるんですが・・・。
もし息の根止められるとしたら、フロント用アプリケーションを書くための言語もろもろではなく、「ＳＱＬというスクリプト言語」でしょう・・・

元のテストは確かにDBサーバが対象ですが、「SSDによってディスクI/Oのボトルネックが解消されるとスクリプト言語にとっては不利である」という考察は、DBサーバかどうかに関係なく成り立ちますよね？

apollo440 2010/04/27 21:46
いやいやいや、”全”プログラマーって。ストレージ使うのが当たり前じゃない世界もあるし、もうちょと範囲狭くして欲しい気が。
あと、(人気の)スクリプト言語は、「使いやすい」じゃなくて「遊びにはよい」かと。

まあ『ストレージ使うのが当たり前じゃない世界もある』のはその通りですが、元記事の興味深い結果はストレージに関係ないプログラマでも知っておくべきでしょう。

noname 2010/04/28 00:56
C++, javaで生活している者から一言

スクリプト屋（笑
が必死だなｗ

お互い様ですね。

negi 2010/04/28 18:04
仕事でjavaからphpに移って6年くらいだけど、
スクリプト言語は
実行速度やコード書く速度とかより
バグが激しくてテストが半端ないよ。
誰かが書いたソースを使いたく無いし、
使おうと思うとソースの細部まで読まなきゃならなくなる
せめて返却値くらいは型を決めてくれ。
NULLの場合とBoolの場合とがあるって糞でしょ？
あとExceptionもだね。
俺もOCamlが何で流行らないのか疑問なんだよね。
OCamlは関数型言語で手続き型から移行しやすい言語だと思う。
まあデフォルトで日本語使えねーって事もあるかもね。
camomileも開発止まってるのかな？
他はHaskellに期待してます。
スクリプト屋は一度、静的型付けの関数型言語をかじった方がいいと思うよ。

前半は言語よりも開発者の能力に大きく依存する話。C++やJavaでその問題が解決するわけではありません。
後半のOCamlについては、単に普及させようとする人の熱意と戦略が足りないだけだと思います (怒られそうだけどあえて言う)。最後の一文は強く同意します。逆にC++やJava屋さんはスクリプト言語をひとつぐらいマスターすべき。