«前の日(04-27) 最新 次の日(04-29)» 追記

Matzにっき


2004年04月28日

_ [TV]“北風より太陽”によって米国でデジタルコンテンツとPCが栄える?

インプレスPCウォッチの「後藤貴子の米国ハイテク事情」より。

要するに厳しいDRM(Digital Rights Management)を採用した日本より、 緩いDRMを採用したアメリカの方がコンテンツ産業が反映するのではないかとの予想。

心から賛同します。

地上波デジタル放送がこのまま計画通りに進んで、 2011年に地上波アナログ放送が予定通り終了したら、 その時私はテレビを卒業します、きっと。

ただでさえテレビだけからしか入手できない情報はどんどん少なくなり、 少ししかないそのような情報の魅力もどんどん下がって、 テレビを見る時間は減る一方なのに、 この上、コピーワンスを強要されて面倒なことになれば、 もうテレビの価値はないです。 DRMの必要性を否定するまではしないけど、コピーワンスがデフォルトはやりすぎ。 そのためにテレビを買い替えるとか、チューナーを買い足すなんて馬鹿馬鹿しい。 あと、7年あったらインターネットが十分代替になると確信します。

その時うちのテレビはビデオとDVD(と将来登場する何か)のプレイヤーになることでしょう。 それでも十分だと思う。

「角を矯めて牛を殺す」ってのはこういう時に使うんだっけ。 「金のガチョウ」の方が適切か。

_ [言語]Babel

おお、前田くんのBabelが単なるSatherコンパイラから進化しようとしている。すばらしい。

私は前者(ネストしない方)が好きです。namespaceの粒度にもよるけど、 きっとかなり大きくなるんじゃないかと思うので、 実質的に無用なネストは増やさないほうが良いのでは、と思います。


2005年04月28日

_ [言語] PEP #340 Anonymous Block Statements

RedHandedより。

PythonにもRubyにあるような「ブロック」を取り入れようというアイディア。

文法はこんな感じかな。

block with_file(filename) as f:
   for line in f:
     print process(line)

これをRubyに翻訳するとこんな感じか。

open(filename) {|f|
  for line in f
    print process(line)
  end
}

Rubyのブロックに似ているのはわざとらしくて、Guido自身も次のように語っている

I think we're on to something. And I'm not too proud to say that Ruby has led the way here to some extent (even if Python's implementation would be fundamentally different, since it's based on generators, which has some different possibilities and precludes some Ruby patterns.)

(超訳)
それなりの案になったと思う。この分野においてRubyの方が進んでいると認めざるをえない。 (Pythonのはgeneratorをベースにしているので実装は全く異なっていて、 Rubyのとは違った(使い方の)可能性があるし、逆にRubyにできてPythonにできないこともあるだろう)

私からの印象は

  • blockキーワードはちょっとうっとうしい。 でも、まだ「仮」だそうだから、実際には違うものになるだろう。
  • asキーワードもあんまりピンとこない
  • generatorを使っているので、blockに使うメソッド(関数)は専用のものが必要。 Rubyのように「ブロックが与えられたら動作が変わる」タイプのものは実現できない。 名前を考えなくてすむのはRubyの方がありがたいが、 きちんと区別したい人にはPythonのやり方を好むかもしれない(私は強制されたくはないが)。
  • else節をつけられるのはPythonのループ類の特徴。 便利な局面もあるらしい。 Python以外ではあまり見かけないが、ずっと以前にどこかで見たようなおぼろげな記憶が。
  • Pythonの文法の制約から(それとgeneratorを使っていることから)ブロック付き関数は値を返せない。 Rubyでのブロック付きメソッドの使われ方から考えると、 これは結構厳しい制約だと思う。魅力半減以下というかなんというか。

まあ、対抗する立場の人からのコメントなので話半分に聞いてほしい。 いずれにしても我々のアイディアが広く受け入れられるのは嬉しいことだ。

_ 論文

去年の夏に出した論文の査読が終わって帰ってくる。いやあ、長かった。

そして査読の結果を見ると...すみません、...私が悪うございました。 はっきりいって論文をナメてました。いや、書いてる時は自覚してませんでしたけど、 未定義の言葉とか、考察が足りないところかが満載なのが厳しく指摘されてました。

これにくじけず再挑戦しますです。書き直す時間を取らなきゃ。 こんどはもっとマシにしなきゃな。


2006年04月28日

_ [Ruby] Ruby on Railsトレーニングプログラム

最初は「30分ほどRubyの紹介とイントロを」という依頼だったのだが、 「Railsの概要も含めて1時間」という依頼になり、 ついに「午前中2時間」という話になった。

だんだん分量が増えていくのであった。ぐすん。

スライドを準備しないといけないし、 なんでも講師はスーツ装備だそうで、 セミナー参加者は 世にも珍しいまつもとのサラリーマン・コスプレが目撃できることになりそう。

実はまだ若干の空きがあるみたい。 とはいえ、本番まで時間はないし、GWになっちゃうし、 金額は高いし、駆け込み参加者はいないだろうな。

_ [Ruby] Gosling on Ruby

Don Box氏による『「Javaの生みの親」に聞く「AJAX、LAMP、Ruby on Rails」』への反応。 ちなみに私の反応はこちら

From where I sit, Ruby has the language thought leadership position and is the competitor I hope AndersH is losing the most sleep over nowadays.

The fact that the "father of Java" is so unconcerned makes me wonder if Schwartz's first act as the grand poobah at Sun should be to hire Matz?

(超訳)

私から見れば、Rubyは言語アイディアの先端を行ってて、AndersHが(心配で)夜も寝られないくらいだといいなと思っている。

「Javaの父」がそんなに関心がないってことは、SchwartzがCEOになって最初になすべき仕事はMatzを雇うことなんじゃないかって思っちゃうよ

ありがたいことだ。 もっとも、Sunに雇われてる間に勢いを失った言語(SelfとかTclとか)のことを 考えると、たとえオファーがあっても素直に「うん」とは言えないかもしれない。 海外(欧米)に住むのが長年の夢である妻は大喜びするかもしれないけどね。

ところで、Wikipediaに「Yukihiro Matsumoto」なんてエントリがあるなんて知らなかったよ。 うわっ、NaClのエントリもある。

_ ITmedia エンタープライズ:オープンソースの輝ける未来は地方自治体がスクリプト言語を担ぐこと−OSDL平野氏

ちょうど我々が島根県や松江市とやろうとしていることと 方向性が同じで驚愕してしまう。偶然の一致か。

地方自治体はスクリプト言語を使った産業を速やかに支援すべきではないかと思います。もし、需要から考えて供給が極端に不足している、XML、 Javaスクリプト、PHPやPhythonをまともに扱える技術者が100人、いや、10人いるような地場企業なら、それがどの県の企業であっても、確実に世界中が注目します。Ajaxやオープンソース版.NETであるMonoの技術者が何人かいただけで、MicrosoftやGoogleですら目を向けるでしょう。優秀な技術者を世界中から求めている企業にとって、その場所が青森県であるか鹿児島県であるかなどはさして問題ではないのです。宮城県に PHPの優秀な技術者を多数抱える地場企業があれば、楽天が野球以外で目を向けますよ(笑)。

スクリプト言語が今後向かう道、それをWeb 2.0のような切り口で語るのではなく、オープンソースまたはオープンソースアーキテクチャーといった切り口で考えると、オープンソースの輝ける未来は地方自治体がスクリプト言語を担ぐことです、と言いたいですよ。

この記事を見るかぎりでは島根県とかRubyとかは一言も出てこないから、 むしろPHPやPythonを念頭に置いていて、方向性が重なったということなんだろうなあ。

まあ、第三者が独立に同じことを思いつくのは 良いアイディアである証拠である...といいなあ。


2007年04月28日

_ [言語] Unifying events and threads

Haskellでイベントモデルとスレッドモデルを融合した 新しい並列実行モデルを実装したという話。 Linux上のI/OベンチマークでNTPLよりも高速だったそうだ。 ふむ。

まだ論文は読んでない。

_ [Ruby] ITキャリア大図鑑:No.003・まつもと ゆきひろ|パソナテック(PASONA TECH)

「Rubyな生き方について」。 4/16から公開されていたが紹介するのを忘れていた。

改めて読み返してみると、私は変なキャリアを生きてるよなあ。 ただ、「自分の環境をデザインする」という考え方は 誰にも応用できる発想だと思う。

_ [言語] twitterブームの陰で注目を集める“Erlang” − @IT

Erlangの紹介。

@ITみたいなメジャーなサイトでErlangが紹介される日が来るとは。 しかも、私のエントリもリンクされてるし。

Erlangのやり方に時代がやっと追いついてきた、ということだと思う。 もっとも純粋に言語としてみた時のErlangは少々とっつきにくい。 記法にPrologの影響が強すぎるのかもしれない。 あと、エラーメッセージがぜんぜん直感的でない。

もっとも、最大のとっつきにくさは私の関数型言語への苦手意識という 非常に個人的なものなのかもしれない。

_ [言語] PragDave: A First Erlang Program

達人プログラマーDave Thomasによる最初のErlangプログラム。 これくらいなら別に難しくもなんともないんだけどねえ。

_ [Ruby] Headius: What Would I (Will I?) Change About Ruby

4月のブログコンテストのエントリを勝手に批評するシリーズ(その6)。 最後はJRubyのCharles Nutterのもの。

実際にRuby処理系を実装しているだけあって具体的。

  • Threading

    Thread#kill, Thread#raise, Thread#criticalをなくしたい。

    Thread#criticalをなくすのは規定路線。前二者はJavaのスレッドでは 提供されていない機能だからCharlesがなくしたいというのはもっともである。 これらはいずれもより抽象度が高い機能(timeoutとか)を実装するための道具 なので、それらが別の形で提供されるなら(段階的に)取り除いてもかまわない

  • ObjectSpace

    なくしたい(特にeach_objectとか_id2refとかだと思う)。

    _id2refについてはThread同様、上位機能(weakrefとか)が実装できれば 問題なし。そのために「_」で始まる名前にしてるんだし。

    残りはメソッドのうち、garbage_collectはGCをスタートするだけだから問題ないはず。 each_objectは悩ましいところだが、デバッグ用のオプションを必要として普段は動かないとかは 許容されるかもしれない。こういうのが必要なのはどうせハックだし。 後はfinalizer関係だが、これらはなくすわけにはいかないと思う。

  • $SAFE and tainting

    Charlesの意見は「これらはいらない」というもののようだ。 それなりに便利なのに。

    が、$SAFE=4のSandboxは_whyのSandboxのようなもので 実現すべきであるという意見はもっともだと思う。 $SAFE=1だけ残すというのが良いのかもしれない(2.0以降)。

    「Javaのsecurity modelにマップすべきだ」という主張は 私自身の知識が足りなくてイメージできなかった。 個人的にはJavaのsecurity modelには「繁雑」という印象しかないんだけど。

  • Direction

    非技術的なのであえて具体的にはコメントしない。 もっともなことだとは思う。

    • Ruby needs a spec.
    • Ruby needs a non-profit governing body.

«前の日(04-27) 最新 次の日(04-29)» 追記