東京出張。多いぞ。
秋葉原ダイビルの東大オフィスで ささだくんと会う。 ま、懸念材料はおおかた金曜日に片づいた(本当に？)なので、 さほど難しい話はしなかったが。
途中でB4の学生さんが来て、彼の課題である
RHC (Ruby High-performance Computing)HPR (High-Performance Ruby) について
現状を聞かせてもらった。
大変興味深いうえに、楽天技術研究所の研究テーマとややかぶっていたので 面白く聞かせてもらった。まだはじまったばかりだけど。 これは産学共同を考えるしかないか。
結城さんとの対談についてのおくじさんの感想。
「変えないほうが楽」だなんて、 まともなソフトウェア開発をやっている人間なら、決して言葉は吐かないはず
いや、まあ、多くのフリーソフトウェア開発者ならそうであるという点においては 同意しますが(だからこそ、「Rubyは変わり続けている」わけで)、 しかし、「まともなソフトウェア開発」とくくってしまうのは ちょっと広すぎるかもしれない。
「フリーでないソフトウェア開発はまともでない」という主張でない限り。
結城さんは執筆者でソフトウェア開発は本業ではない、というのもあるかもしれないけど、 「変えない方が楽」と考える職業的ソフトウェア開発者もたくさんいる。 当然だがこの「変えない」の対象は「外面からわかる点」である。 外側は変えないでリファクタリングや性能向上だけ考えていた方が楽という意味だ。
もう一つ、
分散化が必須という状況では、言語なり処理系なりが透過的な機能を提供して、それで本当に嬉しいの？と思うのです。
そりゃあ、中にはいわゆるバカチョンパラレルで十分なケースもあるわけで、そういう時には嬉しいのかもしれません。
おっしゃることはよくわかる。しかし、私は今後「いわゆるバカチョンパラレルで十分なケース」が増えると考えていて、それを支援したいと考えているので、HPCをRubyで、というわけではない。 Rubyが本質的に遅いことはわかっりきっていても、それでも「もっと速く」という人は絶えないわけで。 本気で「並列で性能！計算速度命！」とかいう話なら、そりゃ明示的な指示は必須だろうし、 そもそもRubyみたいな言語を使う気にならないだろうけど。
最近だとFortressがそういうHPC分野で透過的な言語を目指して、あまりうまくいっていないようですね。
某所にある楽天データセンター(の一つ)を見学させていただく。 データセンターってどこも住所を明らかにしないのね。 テロ対策？
規模やらなんやらに感動する。 滅多に見れない大きなコンピュータや、サーバのつまったラックの数もそうだけど(60テラのディスクとかはじめて見た)、 一番感動したのは、将来にわたって拡張しやすいように、考慮され、企画され、整然と構成された データセンターの「仕組み」である。 過去、いろいろ「痛い目」にあって学んだことが活かされているのだそうだ。 過去のデータセンターでは、ネットワークケーブルが地層になったり、 電源ケーブルとネットワークケーブルが絡んだり、 マシンが重すぎて床が沈みそうになったり、 大変なこともあったのだそうだ。
一緒に見学に参加した、うち(NaCl)の社長は、 「楽天はデータセンター設計部門を子会社化して事業化すべきだ」と 強く主張していた。本当にそうかもしれない。
おお、面白そうな記事が出たのぉ、と思って読み始めたら 自分の書いた文章だった。最近、オープンソースマガジンや 日経ソフトウェアに書いた記事がWebに転載されることが多くて(それは契約の範囲内なので何の問題もないのだけど)、
面白そう→結局自分の記事だった
ということが頻発している。うれしくない。
各種言語の簡単なまとめとリンク。
HTMLとかXMLのようなプログラミング言語でないものが含まれていたり(AcronymにLanguageを含んではいるけど)、 Euphoriaのようなあまり知られていないものが含まれていたりするのが面白い。
一方、Rubyはまだ名前さえ含まれていない。
あ、そうそう。Euphoriaは最近オープンソース化されたそうだ。 いわゆる「今風の言語」ではないけれど、要チェック。
1年ほど仕事でOCamlを使って感じたOCaml言語のダメなところ、という話。
私自身はOCamlを使っていないし、まだ『4839923116』も完読していないので、この批判が正当なものかどうか判断はできないけれど、 今まで言語批判を読んできた経験から推測すると、 大半は設計思想との見解の相違で、 ごく一部正当なものがあるというところだろうか。
もっとも、このような批判が出ることそのものは非常に健全で、 このような批判を改めて検討することで、 自分の設計思想が本当に正しいのか再確認するチャンスを得ることになるし(時間を使ってしまうけど)、 また、今まで思いつかなかった発想の源になる可能性もある。
というわけで、Rubyに対する批判も甘んじて読もうと思っているのだ。 時々、心が痛むけれども。
Python 3000に対するBlog界の反応。
なんとなくforkを懸念する否定的な意見が目立つような気がする。 ま、実際、現行PythonとPython 3000との間で(当初の予想よりはるかに小さいものの)、 非互換性があるのは確かで、結果的に、いつまでもPython 2.xにとどまる人と、 積極的にPython 3.xに移行する人の分断が、ある程度発生することは避けられないと思う。
が、それはしょうがないんじゃないかなあ。 誰かも書いてたけど、Perl5とPerl6よりは小さいわけだし。 たぶん、Ruby1.8とRuby1.9の間よりも小さい。
その辺を気にするのがPython的コミュニティってこと？
いや、邪推が過ぎるか。
こっちにもPython 3000リンク集を発見。
かつてSmalltalkerであったRick DeNataleがRubyに対して思うところ。
いろいろ面白いことがあって、言語に興味があって英語にさほど抵抗がない人には ぜひ読んでいただきたいのだが、個人的に一番面白かったのは以下の引用部分。
I always thought that Smalltalk would beat Java, I just didn't know that it would be called "Ruby" when it did.
私はいつかSmalltalkがJavaを打ち倒す日が来ると信じてきたが、 そうなった時には、それがRubyという名前で呼ばれるとは思いもしなかった。
−Kent Beck
ま、実際問題、Rubyはいろんな意味でSmalltalkではないのだが、 それなりに(頭の柔らかいSmalltalkerに嫌われない程度には)、 Smalltalkの精神を受け継いでいる、らしい。
David Alan Blackによるエッセイ。
新たにRubyを学ぶ人は今まで慣れ親しんだ言語との違いが気になって、 「ここがおかしい」、「あそこを直したい」と感じるみたいだけど、 ちょっと待って。Rubyにはそれなりに歴史と理由があるんだから、 しばらくとどまって、「Ruby流」に慣れてからそのことを考えようよ。 決して後悔しないから。
というような話。
ま、実際「Rubyを変えたい」という話の大半は 「私の知ってる言語XXXとここが違う(から直したい)」というものであるので、 そうしていただけると、私は助かる。
が、そういうリクエストの中にも有意義なものがあったりするから油断がならない。
パフォーマンス(の多く)は処理系の性能よりもアプリケーションアーキテクチャで決まる、という話。 割と当たり前。
The performance boosts associated with a “faster” language would give us a 10-20% improvement, but thanks to architectural changes that Ruby and Rails happily accommodated, Twitter is 10000% faster than it was in January
より「高速な」言語を使うことで性能は10-20%程度向上するだろう。 しかし、RubyとRailsで容易に実現できるアーキテクチャ変更のおかげで Twitterは１月と比較して10000%高速になっている
10000%って100倍だよね。