日曜に録画したサンダーバードを息子を保育園につれていく前に一緒に見る。
私は4歳くらいのときにサンダーバードに夢中だったそうなのだが、息子も感動してみていた。 娘たちはさっぱり興味がないようなので、こういうところに男女差が出るのか。 別にとりたてて男らしく育てたつもりはないのだが。
4891003383 とある野望のために『4891003383』を購入する。 『CODE』といっても4881359932じゃなくて、Petzoldの。 もちろん、Creative Commonsは面白い考えだし、Lessig教授にも注目してはいるんだけど。
知らなかったけどPetzoldって人はWindows関係の本をたくさん出している人なのね。 で、『CODE』での説明は...うーん、私の好きなタイプじゃないなあ。 まあ、このような本が本当に必要な人に伝われば、私が好きかどうかは関係ないんだけど。
ずっと ベルトにさげたケースにVisor Edgeを入れて便利に使ってきたのだが、先日とうとう破損してしまった。 で、しかたがないのでEdgeをかばんに入れているとそれはそれは不自由だ。 やはりいつも持っているということに意義があるのだなあ。
とうことで、明日東京に行った時にでもさっそく新しいのを購入しよう。 田舎ではそんなものはなかなか売っていないのだ。
来週の「オープンソース政策についての討論会」と７月のOSCONのチケットが確保できた。 席が取れないかも、とちょっと焦った。 こんどはもうちょっと早く行動を開始しよう。
以前に
1.8.0では以下のいずれかになるのでは。
- BlockとProcは親子ではない。BlockとProcとMethodがある。生成方法が異なる
- Blockが残り、ProcはMethodとunifyされる。実装が大変。
- BlockはProcに戻る。無名関数オブジェクトはMethodにunify。実装が大変。
などと書いたが、その後改めて検討した結果ProcのMethodのUnifyは無理であることが判明。 となると(2)や(3)は採用できない。
そこで原点に帰って考え直してみた。
元々の動機は「ブロック引数で得られる『ブロックオブジェクト』とlambdaで得られる『手続きオブジェクト』は違うものではないか」という疑問に対する対応だ。
実際このふたつは違うもので、異なる挙動が要求されている(仮に前者をBlock、後者をProcと呼ぶ)。
それが理由でこのふたつのオブジェクトを異なるクラスに分離しようと考えたのだ。 ところが、実際にCVS版でBlockとProcを分離したところ、
という注文が付いた。困った。
そこでしばらく考えたところ、なにもこの2種類のオブジェクトのクラスを分ける必要はないことに気がついた。
仮にlambdaの定義が
def lambda(&block)
Proc.new{|*args|
# 引数の数チェック
begin
block.call(*args)
rescue LocalJumpError => e
case e.reason
when :break, :next, :return
return e.exit_value
end
raise e
end
}
end
のようなものだったら、別に同じクラスで挙動が違うことは十分に説明できるだろう。 実際にはこのような形では実装しないし、arityの調整も行わなくちゃいけないけど、 あくまでも概念としては。
ということは、非互換の素であるBlockというクラスの導入も不要だし、 新しいクラスについての説明も、その使い分けも不要だ。
ということで、これをもって長らく悩んできた「Block/Proc問題」は解決ということにしよう。
あとは、20日午後5時(日本時間)を予定しているpreview3のリリースまで、きちんと準備していくだけだな。
ライセンスの話をしているとオープンソースに関する裁判についても話題になることが多い。
法律の素人の私がえらそうなことを言ってはいけないのかもしれないけど、 日常生活以上に裁判を心配する必要はないだろうと考えている。 また、裁判に関してライセンスはさほど役に立たないとも考えている。
オープンソースソフトウェアに関連して裁判が起きたケースはまだまだ少ないけれど、 考えられるパターンは以下のいくつかに大別できるように思う。
他のパターンがあるだろうか。
さて、これらを見てみると、(1)だけは開発者が訴えるケースで、残りが訴えられるケースだ。 訴えるケースについては後で考察しよう。
残りについてだが、まず(3)と(4)に関してはライセンスは全く関係ない。 よってライセンスをどのように選んでも避けようがない。 曖昧な「気をつけようね」以上の対応策はない。
それから(2)の損害賠償だが、多くのライセンスには無保証の文言が含まれているし、 たとえ含まれていなかったとしても、すべての情報が公開され、無償で提供されているソフトウェアについて 損害賠償が行える契約が締結されていると見なすことは困難だと思われる。 はっきりとしたことは専門家に聞かないといけないけど。
となると、ライセンスをどう選んでも訴えられることに関してはさほど差がないのではないだろうか。
最後に(1)の自分が訴える方だが、これは開発者の自発的なアクションなので好きに選んだらよい。 しかし、裁判という手段に訴えるよりは、ライセンス違反を広く公言して圧力をかける方が効果的ではないか、 という気がしている。
当選者にTシャツ送りました。数日で届くのではないかと。
サインを希望された方がいらっしゃいましたが、 布に書くのは難しくて、醜くなってしまいました。ごめんなさい。
しかし、島根や京都、東京は不自然ではないのに、北海にはとても違和感があるのはなぜだろう。 やはり「道」は別物なのか。
原稿書き。今日が〆切なのだ。今月のテーマは「動的な言語とDuck Typing」。
先月、継承の解説のところで一部触れた動的型についてきちんと解説してみようという試み。 先月同様、これもあんまりまとめて解説したことがなかったので、良い機会だ。
とはいうものの、あまり解説されなかったのにはそれなりに理由があったようで、 めちゃめちゃ説明しにくい。結局、FORTRANとLispの対比のような歴史蘊蓄に満ち溢れた「怪作」になった。 これは毎月のことか。
書くのが難しかったので、一時は間に合わないかと思ったが、 最終的にはなんとか間に合った。良かった。
いわゆる「長崎方式」について。
長崎県以上に、過疎化・地域格差の犠牲になりつつある島根県に住み、 島根県庁からの仕事も積極的に引き受けている関係上、 金は無く、人材も不足しているが、時間だけはなんとか捻出できそう、 という地方自治体の状況についてはわからないでもない。
が、個人的には、この「長崎方式」についてはまだ懐疑的だ。 そうでもしないと大規模ベンダーにみんな仕事を持っていかれてしまいかねない、 という懸念を理解してもなお、
という点が不安だからだ。
まあ、「だから、こうしたほうがいい」という対案はないのだが、
はひとつの方策としてありえると思う。 まあ、それだけで問題がぜんぶ解決するほど世の中は甘くないのだが。
Ruby on Railsを使ったインターンシップの話。 優秀な学生は３年間の内定保証が得られるとか。
「使える」新人確保は、うちを含めてどこでも問題になっているので、 良い考えかもしれない。まあ、あまり新人に即戦力を求めるのはどうか、 という声があるのも承知しているのだが、 零細にはなかなか「人を育てる」のが難しいのも事実だ。
今はOJTと称して、「千尋の谷」メソッドだものなあ。 ガンバレ、新人。
「国産検索エンジンを作ろう」という話。
検索エンジンには日本語処理技術とかスケーラビリティとか興味深い技術が目白押しなので、 成果が残る形なら、そういう技術開発を行うことそのものに反対ではないのだけど、 どこまで意味があるのか、 どう意味をつけるのか、ちゃんと考えないと血税の無駄づかいに終わっちゃいかねない不安がある。
で、ちゃんと考えた意味を早い段階で公表して欲しいなあ。
下二人の子を連れて、宍道森林公園でワード活動。 メインの活動はカマドでカレーを作るというもの。
ご飯は電気炊飯器で炊くという点が不徹底ではあるが(これだから文明人は)、 火加減が難しいカマドでの調理にもかかわらず十分においしい。 カレーというのは人類の偉大な発明だと思う。
インド人は素晴らしい。
その他、縄とびしたり、フリスビーを投げたり、いろいろ遊ぶ。 凧揚げが面白かった。うちでも凧、買おうかなあ。
少々くたびれた。
Sweet Expressionは
の導入により、「普通の外見」を持つように定義されたS式。
そこまでする必要があるのか、というと疑問なのだが、 冷静に考えると、あまり宣言してないだけでRubyのやってることもたいして変わらないような 気もしないでもない。結局は通常言語の文法で(ほぼ)Lispのセマンティクスを提供しているし。
未来の言語設計者へ50の質問。
50は多いのでここに書き写しはしないが、 新しい言語をデザインする時に自問してみる価値のある質問が多く含まれているように思う。 ま、主たる目的はどうしたって「楽しいから」になるに決まってるんだけど、 それ以外に、その言語が対象としたい領域や機能などが明確化される、かもしれない。
Ruby (1.8)とJRubyでマンデルブロ集合を計算するベンチマークを行ったところ、
と大差がついた、という話。
ただし、この話には続きがあって、 Charles Nutterからのコメントによれば(彼ってまめにあちこちコメントするよね)、 このベンチマークでは主要な関数が１度しか呼ばれないためHotSpot最適化が効かず、 このような差がついたとのこと。
jruby -J-server -J-Djruby.jit.threshold=0 -O fractal.rb
と起動すれば、JRubyも6.454000と、1.8とほぼ同等(ほんのちょっと高い)性能を示す。
それぞれのオプションの意味は以下の通り。
昨日、プリンタのテストとして印刷したPDF。 最初に印刷するのがこんなタイトルだっていうところで、 すでに病膏肓に入るって感じ。
いわく「初心者向け言語設計における7つの大罪」。
ついやってしまう初心者向け言語設計における「やってはいけないこと」、 それから逆に「やった方がよいこと」。実に参考になる。 この論文は後で時間をとってもう一度考察したい。
しかし、今気がついたけど、この論文書いたのって Damian Conwayじゃん。Perlの。 どういう風の吹き回しなんだろうか。
追記
リンクが切れてるそうで、すみません。 では、こちらを参照のこと。
注意。このエントリはRuby 2.0に入るかもしれない機能について述べていますが、本機能が本当に2.0に採用されるかどうかは、未定です。
Rubyではメソッド定義のdefの中でdefを書くことができるが、 実際にはメソッド定義が遅延されるだけで、あまり役に立たない。
その理由については 原くんのHotlinkインタビューを見てもらうと良いと思う。
まつもと たとえばネストしたメソッドになにか意味をつけるとしたら、それは多分、そのスコープでだけ有効なメソッドを導入するっていうことだよね。
yhara 「ネストしたメソッド」になってしまうんですね。「ネストした関数」でなくて。
まつもと うん、まあ「ネストした関数」でもいいんだけど、でも Ruby にいま「関数」は無い。
yhara 無いですね。
まつもと だから、「関数」って言う新しいものを導入するって形になってしまう、のかな？
yhara 「ネストしたメソッド」っていうのは、なんか不自然な雰囲気がしますね。
まつもと メソッドの中で def を定義した時に何が定義されるかって言う時に、もしそれがメソッドであるとすれば、どっかのオブジェクトに属してないとダメだよね。で、そのスコープにいる時だけ存在するメソッドって何なんだろうって。
ささだ Argument オブジェクトとか作ってとかなんとか、ってなるかもしれませんね。
まつもと でもそれレシーバじゃないからね。「レシーバを省略すると self に行く」っていうルールと違うものを導入しないといけないことになるんだよね。
yhara すごく納得したのでもういいです。僕はもうその主張はしないことにします。
で、それに対するひとつのアイディアとして、「レシーバに対する特異メソッドを定義する」というものを考えていた。
最近思いついた、もうひとつ別のアイディアとして、「ネストしたメソッド定義は関数定義」にするというのもはどうだろうか、と考えた。
具体的には
def foo
def bar(*args)
...
end
bar(1)
end
をコンパイル時に
def foo
bar = ->(*args) do
...
end
bar.call(1)
end
と展開するというものだ。ローカル変数としてのbarにアクセスできるかどうかは未定だけど、 barは「関数」を引数なしで呼び出すことにするのか、lambdaが入っている リードオンリーの変数とするかどちらかだとと思う。
基本的にコンパイル時の問題なので、実装はさほど難しくないと思う。
ただし、問題(デメリット)もあって、十分な議論なしで安易に導入すべきではないとも思う。
やっぱ、導入は難しいかな。