日曜に録画したサンダーバードを息子を保育園につれていく前に一緒に見る。
私は4歳くらいのときにサンダーバードに夢中だったそうなのだが、息子も感動してみていた。 娘たちはさっぱり興味がないようなので、こういうところに男女差が出るのか。 別にとりたてて男らしく育てたつもりはないのだが。
とある野望のために『CODE』を購入する。
『CODE』といってもLessig教授のじゃなくて、Petzoldの。
もちろん、Creative Commonsは面白い考えだし、Lessig教授にも注目してはいるんだけど。
知らなかったけどPetzoldって人はWindows関係の本をたくさん出している人なのね。 で、『CODE』での説明は...うーん、私の好きなタイプじゃないなあ。 まあ、このような本が本当に必要な人に伝われば、私が好きかどうかは関係ないんだけど。
ずっと ベルトにさげたケースにVisor Edgeを入れて便利に使ってきたのだが、先日とうとう破損してしまった。 で、しかたがないのでEdgeをかばんに入れているとそれはそれは不自由だ。 やはりいつも持っているということに意義があるのだなあ。
とうことで、明日東京に行った時にでもさっそく新しいのを購入しよう。 田舎ではそんなものはなかなか売っていないのだ。
来週の「オープンソース政策についての討論会」と7月の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を使ったインターンシップの話。 優秀な学生は3年間の内定保証が得られるとか。
「使える」新人確保は、うちを含めてどこでも問題になっているので、 良い考えかもしれない。まあ、あまり新人に即戦力を求めるのはどうか、 という声があるのも承知しているのだが、 零細にはなかなか「人を育てる」のが難しいのも事実だ。
今はOJTと称して、「千尋の谷」メソッドだものなあ。 ガンバレ、新人。
「国産検索エンジンを作ろう」という話。
検索エンジンには日本語処理技術とかスケーラビリティとか興味深い技術が目白押しなので、 成果が残る形なら、そういう技術開発を行うことそのものに反対ではないのだけど、 どこまで意味があるのか、 どう意味をつけるのか、ちゃんと考えないと血税の無駄づかいに終わっちゃいかねない不安がある。
で、ちゃんと考えた意味を早い段階で公表して欲しいなあ。
下二人の子を連れて、宍道森林公園でワード活動。 メインの活動はカマドでカレーを作るというもの。
ご飯は電気炊飯器で炊くという点が不徹底ではあるが(これだから文明人は)、 火加減が難しいカマドでの調理にもかかわらず十分においしい。 カレーというのは人類の偉大な発明だと思う。
インド人は素晴らしい。
その他、縄とびしたり、フリスビーを投げたり、いろいろ遊ぶ。 凧揚げが面白かった。うちでも凧、買おうかなあ。
少々くたびれた。
Sweet Expressionは
の導入により、「普通の外見」を持つように定義されたS式。
そこまでする必要があるのか、というと疑問なのだが、 冷静に考えると、あまり宣言してないだけでRubyのやってることもたいして変わらないような 気もしないでもない。結局は通常言語の文法で(ほぼ)Lispのセマンティクスを提供しているし。
未来の言語設計者へ50の質問。
50は多いのでここに書き写しはしないが、 新しい言語をデザインする時に自問してみる価値のある質問が多く含まれているように思う。 ま、主たる目的はどうしたって「楽しいから」になるに決まってるんだけど、 それ以外に、その言語が対象としたい領域や機能などが明確化される、かもしれない。
Ruby (1.8)とJRubyでマンデルブロ集合を計算するベンチマークを行ったところ、
と大差がついた、という話。
ただし、この話には続きがあって、 Charles Nutterからのコメントによれば(彼ってまめにあちこちコメントするよね)、 このベンチマークでは主要な関数が1度しか呼ばれないためHotSpot最適化が効かず、 このような差がついたとのこと。
jruby -J-server -J-Djruby.jit.threshold=0 -O fractal.rb
と起動すれば、JRubyも6.454000と、1.8とほぼ同等(ほんのちょっと高い)性能を示す。
それぞれのオプションの意味は以下の通り。
昨日、プリンタのテストとして印刷したPDF。 最初に印刷するのがこんなタイトルだっていうところで、 すでに病膏肓に入るって感じ。
いわく「初心者向け言語設計における7つの大罪」。
ついやってしまう初心者向け言語設計における「やってはいけないこと」、 それから逆に「やった方がよいこと」。実に参考になる。 この論文は後で時間をとってもう一度考察したい。
しかし、今気がついたけど、この論文書いたのって Damian Conwayじゃん。Perlの。 どういう風の吹き回しなんだろうか。
追記
リンクが切れてるそうで、すみません。 では、こちらを参照のこと。
This work is licensed under a Creative Commons License.
_ kdmsnr [Palmの母艦には何を使われていらっしゃいますか?(OS,スケジューラソフト)]
_ まつもと [Linuxノート(Let's note CF-B5ER)です。USB接続で。 同期にはjpilot、インストールには..]
_ ただただし [Petzoldと言えばWindows、だと思ってました]
_ まつもと [どう考えても、それが普通でしょう。私が異常。 『CODE』もよく見るとMicrosoft Pressでした。]
_ naruse [「オープンソース裁判」の1.-4.とその考察はごもっともです。2.の無保証については、自然法にのっとって考えると、著..]
_ はんばあぐ [ライセンスは十分考えた方がよいと思います。いざ(裁判沙汰)というときの保険としてライセンスがあるのだから、いざの可能..]
_ まつもと [ライセンスについて考えた方が良いことについては同意しますが、それが「保険」として本当に有効かというとかなり疑問を持っ..]
_ Lef [保険としての有効性はたしかに疑問があると僕も思っています。 ただ、GPLはアメリカでは弁護士レビューをしてもらってい..]