ウイルス・スパイウェア検査・駆除 用ツール Dr.WEB CureIt! を無償配布中！
長女、次女の中学校の授業参観。
中三は進路についてのオリエンテーションの参観であった。 推薦とか内申とか入試との比率とか。 島根県はまた制度が違うように思える。
っていうか、私の中学時代には こんなに情報が開示されていなかったような気がする。 内申なんてまったく気にしてなかったものなあ。
AJAXによるズームインタフェースのUnicode文字の一覧。
あまり調べものには向かないが、 「Unicodeってこんなに文字があるんだ」ということを 肌で感じることはできる。
ThoughtWorksに行ったJRuby開発者、Ola BiniによるJavaOneレポート。 結構、手厳しい。
リンク先は最終日のものだが、他の日もなかなか面白い。
高階関数を持つ言語(OCaml)のライブラリを精査したところ、
So among 2239 functions defined in OCaml standard library (and whatever libraries I have installed), 87.2% take no blocks, 12.1% take one block, and 0.7% take two or more blocks.
2239関数のうち、関数引数を取らないものが87.2%、 ひとつだけ取るものが12.1%で、ふたつ以上とるものは0.7%であった。
ここからわかることは、プログラミング言語は 99.3%を占める高階関数(ブロック)を0または1個とるものに最適化するべきであり、 めったにない二つ以上ブロックのために、それ以外のものを「ゆがめて」はいけない、 ということ。
Rubyの文法はまさにこの最適化が行われており、 設計時の私の「勘」が、実証された形になっているのがうれしい。
longjmpのコストはそんなに高くない、という話。
改めて考えて見るとsetjmp/longjmpがやってることは、 いくつかのレジスタをコピーするだけなのでそんなに重いわけではない。 (matzrubyを含めて)setjmp/longjmpを多用する処理系が重いのは、 安易に再帰に頼っているからであってsetjmp/longjmpのせいではない。
via retrospections: Andre's Weblog - Blog
「Threadはダメ」という論文。 面白いのは「(ある程度以上複雑な)Threadプログラムは人間に理解できない」という一方で、 「Erlangのような並列性を組み込んだ言語が今後主流にならないだろう」という主張。
Alternatives that replace these languages with entirely new syntax, such as Erlang or Ada, have not taken root, and probably will not. Even languages with minor syntactic modications to established languages, like Split-C or Cilk, remain esoteric.
The message is clear. We should not replace established languages. ...
I believe that the right answer is coordination languages. Coordination languages do introduce new syntax, but that syntax serves purposes that are orthogonal to those of established programming languages.
つまり、「主流の言語(established languages)」には手を入れず、 それらで記述されたタスクを組み合わせる「協調言語(coordination languages)」が 主流になるのではないかという予測。
が、その協調言語が(たとえばRubyで書かれた)DSLだったらどういうことになるだろうか。
AJAXじゃなくてFlashじゃないかと > Unicode Chart
MLはScheme系よりはAlgol系に近いSyntaxということになっていますがダメですかそうですか。:-)
あと、MLにせよRubyにせよ、なんで一つ以上ないし二つ以上の関数引数を取れるようにしたら文法が変わらなければならないのか、よくわかりませんでした。（というわけで、そもそも最初の表が…？？？）
いや、別によろしいんじゃないでしょうか ＞ ML
あの表はちょっと特殊で、Rubyがcode chunkをひとつだけ取る場合を特別扱いしていることを反映しています。
foo(lambda{|x|...})
ではなく、
foo {|x| ...}
となるので。
orthogonalityを考えると、そのような「省略記法」は不要なのですが、高階関数のほとんどが関数引数をひとつしか取らないことを考えると、見栄えの改善になるこの文法にも意味はあるのだ、と言う話です。
DLRのASTって、どのように思われますか。
http://blogs.msdn.com/hugunin/archive/2007/05/15/dlr-trees-part-1.aspxで、Jim Huguninが興味深い内容を書いています。個人的には、John LamoがIronRubyで見せたPythonとJavaScriptとの連携が興味深かったのですが...
いや、それは当然ですが、一つといわず二つでも三つでも{|x| ...}を書いたらいけないのでしょうか？という質問でした。yieldのほうは数字で指定する:-)とか名前をつけるとか…
そうなると、普段使う「ひとつ」のケースに影響が出ちゃう、ってことなんじゃないかと。> 複数のブロック
あれ、単純に「デフォルトでは最初のブロックにyieldする」だけじゃ駄目ですか？ そもそも複数ブロックが不要ならどうでも良い話ですが、「複数ブロックを導入すると単一ブロックの文法にも影響する」という部分がよくわからなかったので…。何度もすみません。
Rubyのブロックを複数渡せるようにできる文法が定義できそうな気がしません。
結構、複雑なことをしているので。
仮に不可能でないにしても、呼び出す方も受ける方も複雑になるわけですから、あまりメリットはないように思います。
> 結構、複雑なことをしているので。
なるほど、実は何か複雑な事情(?)があるんですね…。現状でProcオブジェクトを生成したり、専用のオブジェクトを定義するよりは簡単になるかと思ったので…。どうもありがとうございました。(_ _)
「Haskellのような並列性を組み込んだ言語が今後主流にならないだろう」という主張をされている方もいらっしゃるのでしょうか？
この論文には書いてないですね。
でも、Haskellのような並列性が主流になるかどうか賭けろ、と言われたら、私はならない方に賭けます。残念ながら。
主観的には8:2くらいの確率かな、根拠はないですけど。
ご回答有難うございます。
私は、まつもとさんもご察しの通り、Haskellのような並列性が主流になる方に賭けさせていただきます。
どうか、よろしくお願いします。(?)