なひさんがYAMLなんてWikiページを用意してくださる。 要旨はここへのツッコミそのまま。
で、Wikiなので自分の意見を書き込んでおく。記録のためにここにもコピー。
まつもとからの意見
実際に比較しているのは
なんだよね。
実際、なひさんの意見はXMLについて無知な私にとって非常に参考になる。 でも、こんなことしてないで原稿を仕上げた方が良いな。
私の同僚たちは今日からXPを実践しはじめました。 ストーリー、タスクの抽出など、はたから見る限りは順調のようです。
今は４人でひとつのディスプレイをのぞき込む「カルテットプログラミング」を行っています (私がのぞきに行くと「クインテット」)。まさにエクストリーム。
NHKによる子供向け情報教育ページ「ネタブラカダブラ」が その22話でオープンソースについて扱っている。 NHKがこんな風に扱ってくれるとは時代も変わったものだ。 おおむね適切な表現に涙ぐみそうになる。
【オープンソース】
自分で作ったソフトの「ソース」を無償で公開し、多くのユーザーに自由に使ってもらって、こうすれば使いやすくなるという提案やバグを報告してもらったり、プログラマ同士が「ソース」を改良し合うことで、より優れたソフトを生みだそうという考え方。
うちの子に読ませて、「これでお父さんのやってることが分かった？」と尋ねると、 「だいたい」とのこと。その後、「どうしてソースを隠しちゃう人がいるの？」と聞いてきた。 「お金のためだよ(笑)」と答えつつ、 そうそう、ソースは公開して助け合うのが「普通」なんだよな、と改めて認識する。
昨日のWinnyの件でツッコミをもらう。
まずは、babieさん。
明日の各紙朝刊にのると思いますが、「大阪のほう助事件参考に立件判断」<http://www.kyoto-np.co.jp/article.php?mid=P2004051100113&genre=C1&area=K00>だそうです。立件の背景ですが、朝日新聞の「挑発的な態度」と、この記事の最後の「故意と加罰性」では同じ内容でもニュアンスが変わってきますね。
蛇足ですが「特製Ｗｉｎｎｙで摘発逃れか」<http://www.kyoto-np.co.jp/article.php?mid=P2004051100115&genre=C1&area=K00>という記事もあり、この疑いが事実だとすれば、47氏が逮捕早々から弱気だったのも頷けます。ネットワークにおける自由の行方を占う事件だけに、いやな材料です。
昨日の私の文章は基本的に疑問文である。私は知りたいのだ。 なにが幇助でなにがそうでないかを。なにが言論の自由でなにが制限されるべきものかを。 あるいは今回の件はソフトウェアの自由に関係があるのかないのかを。
私は47氏が特製Winnyを使っていたかどうかはあまり関心がない。 それは「著作権侵害の摘発逃れ」を意図したものであって、 もし彼が著作権侵害をしたというのであれば、 その法律違反にしたがった処分を受けてしかるべきだ。
私が関心があるのは、なにが幇助にあたり、なにがそうでないかだ。
プリペイド携帯電話は犯罪に利用されることがある。 携帯電話会社はそのことを認識しているはずだ。 これは幇助にあたのか。少なくとも可罰性はないらしい。 プリペイド携帯電話に犯罪以外の用途がたくさんあるからか。
ビデオデッキは著作権侵害に利用されることがある。 電機メーカーはそのことを認識しているはずだ。 これは幇助にあたるのか。少なくとも可罰性はないようだ。 ビデオデッキに犯罪以外の用途がたくさんあるからか。
暗号化ソフトウェアは犯罪に利用されることがある。 これは幇助にあたるのか。アメリカではZimmermanが戦った(幇助の罪ではないけど)。 日本ではどうなのか。
今回の件がhinaさんのおっしゃるように、
ただ、違法な用途の為にその道具を作って違法な使い方を説明して配布したなら幇助に値するという事なのでしょう。
ということであり、Winny固有の事情によるものであれば、それはそれで問題ない。
しかし、私自身は確証のないうちから、
だとしたら、法治国家としてこれを放って置かないのは当然です。力ずくの自己主張が力で封じられるのも当然だと思います。 それだから、私は法改正の言論が封じられたという印象は持てないし、日本が危ういとも思えません。
<中略>
この件をきっかけに、この国の自由が危うくなるんでしょうか。 とてもそうは思えません。
と安心してしまうことはできない。
だからこその思考実験である。
違法なことにも利用できる完全匿名のメッセージ交換システムの開発は幇助になるのかならないのか。 その特性から管理も責任の追及も不可能な場を存在させてしまうことは、その行為そのものが罪なのか。
8月1日から5日までのOSCON 2005のプログラムが決定した。
今年はちゃんとRubyトラックが用意されている。その内容は以下の通り。
2005-08-04
Yield to the Block: The Power of Blocks in Ruby
Yukihiro Matsumoto, netlab.jp
Location: E143
Time: 10:45am - 11:30amPragmatic Project Automation with Ruby
Mike Clark
Location: E143
Time: 11:35am - 12:20pmA Starry Afternoon, a Sinking Symphony, and the Polo Champ Who Gave It All Up for No Reason Whatsoever
why the lucky stiff
Location: E143
Time: 1:45pm - 2:30pmMetaprogramming Ruby
Glenn Vanderburg, Principal, Delphi Consultants, LLC
Location: E143
Time: 2:35pm - 3:20pmDependency Injection: Vitally Important or Completely Irrelevant?
Jim Weirich, Consultant, Compuware
Location: E143
Time: 4:30pm - 5:15pm2005-08-05
Extracting Rails from Basecamp
David Heinemeier Hansson
Location: Portland 258 & 251
Time: 10:45am - 11:30am
2005-08-01
Introduction to Ruby
Dave Thomas, The Pragmatic Programmers, LLC
Location: E144
Time: 8:30am - 12:00pmRuby on Rails: Enjoying the Ride of Programming
David Heinemeier Hansson
Location: E144
Time: 1:30pm - 5:00pm2005-08-04
High Order Bit: Secrets Behind Ruby on Rails
David Heinemeier Hansson
Location: Portland Ballroom
Time: 9:00am - 9:15am
DHH大活躍。それ以外にもおもしろそうなものが多い。 しかも、RubyトラックなんざOSCON全体から見たらほんの隅っこの一部に過ぎない。 参加するのが楽しみだ。後は金の工面を。
ちょうど東京にいるから、ということでTech総研から取材を受けるためにリクルートへ。
で、うっかり、新橋で降りるべきところを銀座で降りてしまい、 一駅分歩く。かばんが重い。交番で地図を見ならが「遠いなあ」とつぶやいたら、 横にいたおじさんが「若いんだから、歩く歩くっ」ですって。
もう、そんなに若くないんですけど。童顔だけど。
で、取材。先日調べていたChasmの話とかも含めて、なんかぐだぐだとしゃべったけど、 記者のヒトがうまくまとめてくれるのかなあ。 カメラマンに写真を撮ってもらうという経験が恥ずかしい。 掲載は6月末だとか。
Tech総研とはTech Bingの後継のWebマガジンだそうだ。 いつの間にかTech Bingなくなってたんだねえ。 そういえば以前に聞いたことがあったような(すっかり忘れている)。
応募次第などについて。とっくに決まっているはずだったんだけど、 ちょっと作業が遅れているみたい。でも、まあ、重大な問題もなく進みそうだ。
後はどれだけの人が応募してくれるかだ。
我々は君の応募を待っている。 と、よしおかさんも言っている。
今回は上野の某ホテルに4泊したのだが、
なんとかならないものだろうか。ならないかな。
長女、次女の中学校の授業参観。
中三は進路についてのオリエンテーションの参観であった。 推薦とか内申とか入試との比率とか。 島根県はまた制度が違うように思える。
っていうか、私の中学時代には こんなに情報が開示されていなかったような気がする。 内申なんてまったく気にしてなかったものなあ。
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だったらどういうことになるだろうか。