«前の日(06-15) 最新 次の日(06-17)» 追記

Matzにっき


2003年06月16日

_ [TV]サンダーバード

日曜に録画したサンダーバードを息子を保育園につれていく前に一緒に見る。

私は4歳くらいのときにサンダーバードに夢中だったそうなのだが、息子も感動してみていた。 娘たちはさっぱり興味がないようなので、こういうところに男女差が出るのか。 別にとりたてて男らしく育てたつもりはないのだが。

_ [本]CODE

4891003383 とある野望のために『CODE』を購入する。 『CODE』といってもLessig教授のじゃなくて、Petzoldの。 もちろん、Creative Commonsは面白い考えだし、Lessig教授にも注目してはいるんだけど。

知らなかったけどPetzoldって人はWindows関係の本をたくさん出している人なのね。 で、『CODE』での説明は...うーん、私の好きなタイプじゃないなあ。 まあ、このような本が本当に必要な人に伝われば、私が好きかどうかは関係ないんだけど。

_ [Palm]ケース破損

ずっと ベルトにさげたケースにVisor Edgeを入れて便利に使ってきたのだが、先日とうとう破損してしまった。 で、しかたがないのでEdgeをかばんに入れているとそれはそれは不自由だ。 やはりいつも持っているということに意義があるのだなあ。

とうことで、明日東京に行った時にでもさっそく新しいのを購入しよう。 田舎ではそんなものはなかなか売っていないのだ。

_ チケット確保

来週の「オープンソース政策についての討論会」と7月のOSCONのチケットが確保できた。 席が取れないかも、とちょっと焦った。 こんどはもうちょっと早く行動を開始しよう。

_ [Ruby]BlockとProcとMethod

以前

1.8.0では以下のいずれかになるのでは。
  1. BlockとProcは親子ではない。BlockとProcとMethodがある。生成方法が異なる
  2. Blockが残り、ProcはMethodとunifyされる。実装が大変。
  3. BlockはProcに戻る。無名関数オブジェクトはMethodにunify。実装が大変。

などと書いたが、その後改めて検討した結果ProcのMethodのUnifyは無理であることが判明。 となると(2)や(3)は採用できない。

そこで原点に帰って考え直してみた。

元々の動機は「ブロック引数で得られる『ブロックオブジェクト』とlambdaで得られる『手続きオブジェクト』は違うものではないか」という疑問に対する対応だ。

実際このふたつは違うもので、異なる挙動が要求されている(仮に前者をBlock、後者をProcと呼ぶ)。

  • Blockは引数チェックがゆるい。breakやnextが例外になる
  • Procは引数チェックが厳しい。breakやnextは実行の中断

それが理由でこのふたつのオブジェクトを異なるクラスに分離しようと考えたのだ。 ところが、実際に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のリリースまで、きちんと準備していくだけだな。

_ [OSS]オープンソース裁判

ライセンスの話をしているとオープンソースに関する裁判についても話題になることが多い。

法律の素人の私がえらそうなことを言ってはいけないのかもしれないけど、 日常生活以上に裁判を心配する必要はないだろうと考えている。 また、裁判に関してライセンスはさほど役に立たないとも考えている。

オープンソースソフトウェアに関連して裁判が起きたケースはまだまだ少ないけれど、 考えられるパターンは以下のいくつかに大別できるように思う。

  1. ソースコードの不正流用
  2. ソフトウェア瑕疵に伴う損害賠償
  3. 商標問題(MySQLとかUNIXとか)
  4. 特許、トレードシークレットの不正使用(SCOのケース)

他のパターンがあるだろうか。

さて、これらを見てみると、(1)だけは開発者が訴えるケースで、残りが訴えられるケースだ。 訴えるケースについては後で考察しよう。

残りについてだが、まず(3)と(4)に関してはライセンスは全く関係ない。 よってライセンスをどのように選んでも避けようがない。 曖昧な「気をつけようね」以上の対応策はない。

それから(2)の損害賠償だが、多くのライセンスには無保証の文言が含まれているし、 たとえ含まれていなかったとしても、すべての情報が公開され、無償で提供されているソフトウェアについて 損害賠償が行える契約が締結されていると見なすことは困難だと思われる。 はっきりとしたことは専門家に聞かないといけないけど。

となると、ライセンスをどう選んでも訴えられることに関してはさほど差がないのではないだろうか。

最後に(1)の自分が訴える方だが、これは開発者の自発的なアクションなので好きに選んだらよい。 しかし、裁判という手段に訴えるよりは、ライセンス違反を広く公言して圧力をかける方が効果的ではないか、 という気がしている。

まとめ

  • ライセンスの選択と訴えられることには実はあまり関係がない。
  • 訴えられることをあまり心配するのは無駄。
  • 裁判についてあまり心配しすぎることはFUD的要素を持つ(だからやめよう)。
  • でも、最終的な判断は専門家に聞かないと(だれか相談に乗ってくれないかな)。

2004年06月16日

_ プレゼント発送

当選者にTシャツ送りました。数日で届くのではないかと。

サインを希望された方がいらっしゃいましたが、 布に書くのは難しくて、醜くなってしまいました。ごめんなさい。

しかし、島根や京都、東京は不自然ではないのに、北海にはとても違和感があるのはなぜだろう。 やはり「道」は別物なのか。


2005年06月16日

_ [原稿] 日経Linux 8月号

原稿書き。今日が〆切なのだ。今月のテーマは「動的な言語とDuck Typing」。

先月、継承の解説のところで一部触れた動的型についてきちんと解説してみようという試み。 先月同様、これもあんまりまとめて解説したことがなかったので、良い機会だ。

とはいうものの、あまり解説されなかったのにはそれなりに理由があったようで、 めちゃめちゃ説明しにくい。結局、FORTRANとLispの対比のような歴史蘊蓄に満ち溢れた「怪作」になった。 これは毎月のことか。

書くのが難しかったので、一時は間に合わないかと思ったが、 最終的にはなんとか間に合った。良かった。


2006年06月16日

_ 「地方自治体に金はない、残されているのは時間だけ」--長崎県

いわゆる「長崎方式」について。

長崎県以上に、過疎化・地域格差の犠牲になりつつある島根県に住み、 島根県庁からの仕事も積極的に引き受けている関係上、 金は無く、人材も不足しているが、時間だけはなんとか捻出できそう、 という地方自治体の状況についてはわからないでもない。

が、個人的には、この「長崎方式」についてはまだ懐疑的だ。 そうでもしないと大規模ベンダーにみんな仕事を持っていかれてしまいかねない、 という懸念を理解してもなお、

  • 本当に要求仕様を県CIOが書けるのか
  • 開発者が全体を把握しなくなるのは良いことなのか
  • コードの重複、フレームワークの欠如などの問題が発生しないか

という点が不安だからだ。

まあ、「だから、こうしたほうがいい」という対案はないのだが、

  • オープンソースを積極的に利用することによって
    • コスト削減
    • 零細SIerの競争力強化

はひとつの方策としてありえると思う。 まあ、それだけで問題がぜんぶ解決するほど世の中は甘くないのだが。

_ ECナビ、自社の研究組織「ECナビラボ」で、学生のインターンシッププログラムを開始

Ruby on Railsを使ったインターンシップの話。 優秀な学生は3年間の内定保証が得られるとか。

「使える」新人確保は、うちを含めてどこでも問題になっているので、 良い考えかもしれない。まあ、あまり新人に即戦力を求めるのはどうか、 という声があるのも承知しているのだが、 零細にはなかなか「人を育てる」のが難しいのも事実だ。

今はOJTと称して、「千尋の谷」メソッドだものなあ。 ガンバレ、新人。

_ 「Google独占にはさせない」--国産検索エンジン開発へ、産学官が一致団結

「国産検索エンジンを作ろう」という話。

検索エンジンには日本語処理技術とかスケーラビリティとか興味深い技術が目白押しなので、 成果が残る形なら、そういう技術開発を行うことそのものに反対ではないのだけど、 どこまで意味があるのか、 どう意味をつけるのか、ちゃんと考えないと血税の無駄づかいに終わっちゃいかねない不安がある。

で、ちゃんと考えた意味を早い段階で公表して欲しいなあ。


2007年06月16日

_ [教会] ワード活動

下二人の子を連れて、宍道森林公園でワード活動。 メインの活動はカマドでカレーを作るというもの。

ご飯は電気炊飯器で炊くという点が不徹底ではあるが(これだから文明人は)、 火加減が難しいカマドでの調理にもかかわらず十分においしい。 カレーというのは人類の偉大な発明だと思う。

インド人は素晴らしい。

その他、縄とびしたり、フリスビーを投げたり、いろいろ遊ぶ。 凧揚げが面白かった。うちでも凧、買おうかなあ。

少々くたびれた。

_ [言語] David A. Wheeler's Blog - Readable s-expressions and sweet-expressions: Getting the infix fix and fewer parentheses in Lisp-like languages

Sweet Expressionは

  • インデントベースのブロック化
  • 関数呼出し記法
  • 中置記法演算子

の導入により、「普通の外見」を持つように定義されたS式。

そこまでする必要があるのか、というと疑問なのだが、 冷静に考えると、あまり宣言してないだけでRubyのやってることもたいして変わらないような 気もしないでもない。結局は通常言語の文法で(ほぼ)Lispのセマンティクスを提供しているし。

_ [言語] fifty_questions_for_a_prospective_language_designer [the libarynth]

未来の言語設計者へ50の質問。

50は多いのでここに書き写しはしないが、 新しい言語をデザインする時に自問してみる価値のある質問が多く含まれているように思う。 ま、主たる目的はどうしたって「楽しいから」になるに決まってるんだけど、 それ以外に、その言語が対象としたい領域や機能などが明確化される、かもしれない。

_ [Ruby] Raw Block: Ruby vs JRuby Fractal Benchmark

Ruby (1.8)とJRubyでマンデルブロ集合を計算するベンチマークを行ったところ、

  • Ruby: 6.732136
  • JRuby: 68.757000

と大差がついた、という話。

ただし、この話には続きがあって、 Charles Nutterからのコメントによれば(彼ってまめにあちこちコメントするよね)、 このベンチマークでは主要な関数が1度しか呼ばれないためHotSpot最適化が効かず、 このような差がついたとのこと。

jruby -J-server -J-Djruby.jit.threshold=0 -O fractal.rb

と起動すれば、JRubyも6.454000と、1.8とほぼ同等(ほんのちょっと高い)性能を示す。

それぞれのオプションの意味は以下の通り。

-J-server
Server VMを使う
-J-Djruby.jit.threshold=0
すべてのメソッドをJIT対象にする
-O
ObjectSpaceを使わない

_ [言語] Seven Deadly Sins of Introductory Programming Language Design

昨日、プリンタのテストとして印刷したPDF。 最初に印刷するのがこんなタイトルだっていうところで、 すでに病膏肓に入るって感じ。

いわく「初心者向け言語設計における7つの大罪」。

ついやってしまう初心者向け言語設計における「やってはいけないこと」、 それから逆に「やった方がよいこと」。実に参考になる。 この論文は後で時間をとってもう一度考察したい。

しかし、今気がついたけど、この論文書いたのって Damian Conwayじゃん。Perlの。 どういう風の吹き回しなんだろうか。

追記

リンクが切れてるそうで、すみません。 では、こちらを参照のこと


2010年06月16日

_ [Ruby] Ruby2.0の新機能(かもしれないもの)(2) nested def as local function

注意。このエントリは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が入っている リードオンリーの変数とするかどちらかだとと思う。

基本的にコンパイル時の問題なので、実装はさほど難しくないと思う。

ただし、問題(デメリット)もあって、十分な議論なしで安易に導入すべきではないとも思う。

  • ネストしたメソッドだけLisp-1的動作をするのは、モデルの統一性として問題ではないか。
  • ネストしたメソッドで定義された識別子をリードオンリーの変数とするならば、新しい変数種別を導入することになる。
  • 単体の識別子を引数なしの呼び出しとするならば、lambdaを取り出す手段がない
  • いずれにしてもコンテキストの情報が増えるので、bindingに手を入れなくてはいけない

やっぱ、導入は難しいかな。


«前の日(06-15) 最新 次の日(06-17)» 追記