Re: interface と型チェックの有無 #3
だーかーらー、話題が違うって言ってるでしょうが。なんでこんなにグダグダつっかかってくるの？
こっちで話しているのは「JavaのinterfaceはObjective-Cのprotocolが元ネタであり、本質的に同じ機能である」という話。それを裏付ける資料があるのに、なんでそれらを無視してGoslingが参考にしたかどうかもわからない論文で話を進めるの？誰も型チェックが無意味とか言ってないでしょ？classもinterfaceも、Javaでは型として使われるけど、型チェックのない動的な言語にも導入されて実際に役に立っている。だからclassやinterfaceの機能は型チェックとは関係なく独立して存在できるし、両者は分けて考えることができる。前に書いたように、あなたが「interfaceと型チェックは不可分」と考えるならそれはあなたの自由。ただ自分とは考えが違いますね、で終了。これ以上話しても進展はなし。
続きを読むRe: interface と型チェックの有無 #2
なんというかなぁ、sumim さんの紹介された論文のタイトルが「Interfaces for Strongly-Typed Objecect-Oriented Programming」だというのを忘れていませんか。
interface と型チェックの有無 #2 - odz buffer
いつから、suminさん紹介の論文に関する話題になったんでしょうか。
もともとは Gosling のプレゼン資料にあるように、また中の人の証言にあるように、JavaのinterfaceはObjective-Cが元ネタになっているよね、という話であり、またJavaのinterfaceとObjective-Cのprotocolは本質的に同じもんじゃね？という話です。「intefaceは型チェックを行うべきである」という意見はあってもいいと思いますが、それはここで扱っているのとは別の話ですよね（関連はしてますけど）。
正直、odz氏が何を焦点に話をしているのかよく分かりません。「interfaceでは型が重要である。だからJavaのinterfaceとObjective-Cのprotocolは本質的に違うものだ。」というのでしたら、はいそうですか、自分とは違いますね、で終了です。正直、それ以上コメントしようがありません。ゴメンナサイ。
続きを読むRe: Ruby1.9で遅くなる項目
Ruby1.9での新VMの作者さんからコメントいただきました。わざわざありがとうございます。
たとえば，スレッドはネイティブスレッド化が問題になり，count_words は m17n の影響になります．
count_wordsが8倍以上遅くなるのは謎でしたが、m17nが原因ですか。しかしそうなると、他の文字列処理にも影響を与えるはずです。m17nが原因としてもここまで遅くなるとは思えないし、他のベンチマークは速くなっていてcount_wordsだけ8倍以上遅いというのもやはり解せないというのが正直なところです。
eval に関しては，よくぞ 3 倍で留めたな，という感覚です．ただ，erb は遅くなっていないため（ベンチマークがあります），その辺は問題ないかなぁ，という気もしています．
なるほど。erbではevalが遅くなる代わりに他の処理が速くなっているおかげで、結果として相殺されているんでしょう。そのため、ベンチマークは遅くなっていないかわりに大して速くもなっていない。
ちなみにevalが遅くなる理由って、結局なんなのでしょうか。byte code変換の分だけ1.8より遅くなるのは分かりますが、それだけで3倍の時間がかかるとは思えない。
例外処理については，「例外が発生すると遅い」です．コードを見るとわかると思いますが，例外を連発するベンチマークです．
逆に，例外が発生しないものについてはとても速くなっています．それを確認するベンチマークもあるので，ご参照ください．
これはいい戦略ですね。例外が発生する場合よりしない場合のほうがずっと多いですから、発生しない場合が高速化されるなら、発生する場合が2割程度遅くなるのは十分許容できるでしょう。
なんかCPUの投機実行を思い出しました。
IO まわりは native thread の絡みですね．ただ，この辺はまだまだチューニングできると考えています．
チューニングで速くなればいいんですが。
最近「エンタープライズRuby」というのを聞きますが、もしRubyが本当にエンタープライズを目指すのであれば、I/Oが遅いというのは良くないです（理由がなんであれ）。Native threadが原因ということがわかっているなら、native threadを使わないという選択肢も用意すべきではないでしょうか。
例えばApacheはコンパイル時にthread modelを切り替えられます。それとはちょっと違いますがJavaはJVMの起動時に-clientまたは-serverを指定することで実行モードを切り替えられます。同様に、Rubyでもコンパイル時または起動時にthread modelや正規表現エンジンを指定できる機能があると理想的です。
ただそこまで用意できるほどの開発リソースがRubyチームにあるかどうかわかりませんので、あくまで無責任な外野の一意見としてください。
Re: interface と型チェックの有無
基本的にみずしまさんのコメントにつきるんだけど、なんとために「視点による」と書いたのか分かってもらえてないようで。普通、比較するときは複数の面について比較するでしょ。ある面について違うから比較できないなんて話にはならないよ。
interface と型チェックの有無 - odz buffer
「比較」という言葉の意味が違うということでしょう。
自分がもともと
前に書いた通りですね。型チェックのあるなしで「違う」と見なすのであれば、静的な言語と動的な言語ではそもそも機能の比較ができないでしょう（どうせ全て「違う」と見なされるのだから）。
クラス、インターフェース、型チェックの有無 - usagidropの日記
で書いたときは、「本質的に同じかどうか」という意味で使ってます。「JavaのinterfaceとObjective-Cのprotocolは本質的に同じ機能だが、Rubyのmoduleは本質的に違う」と言及するようなことを「比較する」といってます。そのため、『複数の面について比較』ということはそもそもありえない。
続きを読むチューリング賞モノの大発見： ソートアルゴリズムの計算量は O(n) だった！？
元ネタはここらへん。
読んでみたけど、なんかおかしくね？
このループの回数、見てのとおり常に一定です。上の22というのは、これだけ繰り返せば必ずdoubleの精度に収まるというマジックナンバーです。詳しくは奥村本をご覧ください。
404 Blog Not Found:アルゴリズム百選 - ベキ乗はO(1)でOK?
これはつまり、n に「doubleの精度」という制限をかけて、その範囲でなら O(1) だと主張しているようだ（だから『高々22回繰り返せば良い』といっているのだろう）。
しかしこれは間違いじゃないだろうか。この『22』というマジックナンバーは、n についての制限を取っ払ったらきっと増えていくんじゃない？もしそうなら、この『22』は定数ではなくなるので、O(1) だという根拠にはならなくなる。
続きを読む
