2.6.1もリリースされたのだが、こちらはようやく2.6.0にアップグレード。
2.4のときにはinitrdがよくわからず移行にずいぶん手間取ったのだが、 今回は割とスムーズに。
気がついた点:
引っかかった点:
解決しなかった問題:
visorとのsyncができない。syslogには
Jan 13 13:05:21 ev usbmgr[592]: invalid buffer line
というメッセージ。
Audio CDがアクセスできない。gripでアクセスすると、
のいずれかになる。
いずれもささいではあるが、無視はできない。
午前中は晴れていたのに、午後から急に雲が出てきて、雷も鳴る。雪が降りはじめる。 少し冷えるなと思っていたら、本格的な雪になり、あっという間に積もってしまう。
夜、息子と風呂に入っていたら、停電になる。停電初体験でパニックになりかける息子。 久しぶりの停電でちょっとわくわくする父。懐中電灯を出してきて、 「大丈夫？」と風呂場に確認に来る次女。停電は数分で復旧した。
うむ、次女は緊急事態に強いらしい。こういう時に性格が出るな。
停電で狂った時計を再設定する。 うちだと給湯器と電子レンジの時計以外は停電でもリセットされないから楽だ。
Amazonから荷物が届く。中身は 『4592132793』。
注文もしていないものが届いたので驚いたが、どうやらウィッシュリストを見た人が プレゼントしてくれたらしい。こんなことは初めてだったのでえらいびっくりしたが、 ありがたい。
千代田区の磯辺さん、どうもありがとうございます。この場を借りてお礼いたします。
さっそく読んだが、面白かった。たぶん、以前雑誌で読んだような気もするが、 改めて読んでも十分楽しい。 「4051062228」を読んで以来、 ロケット関係に少々興味がある長女も喜んで読んでいた。
しかし、宇宙開発がある意味停滞している昨今、こんな本や、 『プラネテス』、『ふたつのスピカ』のようなアニメによって 宇宙に対する情熱を持つ子供がふたたび増えてほしいものだ。 最近、熱く宇宙を語る子供になんてなかなか出会わないものなあ。 私のまわりだけかもしれないけど。
人類が月に行ったのが「ぼくらの生まれるずっとずっと前」だという歌の文句に衝撃を受けたものとしては、 今週発表されるというブッシュ大統領の宇宙開発宣言に(たとえそれが選挙向けのポーズだとしても) 期待したい気持ちが強いのだった。
小泉さんもいかがでしょう。そんな宣言出したら、大いに見直すんだけどなあ。
夜は家族が集まる「家庭の夕べ」。本来は月曜日なのだが、昨日は休日だったし、 姪も来ていたので今日に延期されていた。
レッスンは「御霊の導きに従う」。妻による「小さな細い声に耳を傾けましょう」という話。
活動は長女の提案により「かくれんぼ」。狭い家では大人の隠れるところはなかなかないのだが、 精一杯がんばった。が、当然のようにすぐ見つかる。頑張ったのに。子供たちは喜んでいた。 親も結構楽しんだ(子供っぽい？)。 今回は「家の中限定」というしばりがあったので難しかった。 以前はベランダに隠れるというワザを使ったものもいたのだが。
これまでのあらすじ(笑)
XMLは「Javaアプリケーションのスクリプト言語」としての地位を、知らぬ間に獲得しているようだ。 今やXMLは広く受け入れられている。 しかし、私にはXMLは「濫用」されているように思われる。
正直なところ、今さらあれこれ言ってもしかたがないとは自分でも思っているのだが、 やはり技術が不適切に利用されているように思える局面を見ると口出ししてしまうのだ。
しかし、さすがの私もXMLが全面的によくないと思っているわけではない。 元々の目的、つまりマークアップ言語としては十分な機能と仕様を持っていると思うし、 そういう目的に利用されているのを見て、どうこう言おうとは思わない。 自分ではきっと使わないだろうけど、それは別の話。
しかし、データ表現の手段としてのXMLには、いくつか欠点がある。 人によっては「どうでも良い」と思うだろうし、実際、そう思えるからこそXMLが選択されているのだろうが。
その欠点とは、まず第一に「冗長なこと」である。
私はXMLの冗長なところがいいのかな、と。冗長だから人間が誤るのを訂正してくれるわけです。
とあったが、私は全く同意しない。
ある人間が入力したXMLファイルに間違いがある。それは少しも珍しいことではない。 人間は誤るものだ。で、その誤りを検出する方法は、結局は以下のいずれかではないだろうか。
さて、重要なのはこのいずれもがXMLの冗長性、つまりSGML風の<xml>〜</xml>的タグに依存しないということである。ということは、このタグによる冗長性は単に無駄ということではないだろうか。 あのタグに利点があるとしたら、私に思いつくのは「テキストに埋没しない」ことだけであり、 つまりマークアップとして使う時にしか意味がない。
Paul Grahamを引用するならば「簡潔さは力」である。ということは、「冗長性は悪」である。 こと言語に関する限り。よって、XMLは優れた言語ではありえない。
「人間は書かない」、「人間は読まない」から、という反論を見たことがあるような気がするが、 「人間は書かない」、「人間は読まない」データならば別にXMLである必要はない。 ただ、現状ではライブラリが揃っているので安易な選択であることは認める。
もうひとつ、私には欠点に思える点は、XMLは型のない言語である点である。
古代には言語はタイプレスであった。アセンブラには整数しかない(最近のは浮動小数点数もあるけど)。 その数が、単なる整数なのか、アドレスなのか、あるいは文字を表現しているのかは、 コンテキストあるいはその数を処理するプログラムによって決まったものだ。
しかし、それは人間にとっては都合が悪いので、計算モデルとして型が導入された。 BCPLは「型なし」であったが、Cでは型が導入された、というように。
スクリプト言語の世界では、長らく型(と人間性)が軽視されてきたので、Awk(数と文字列に区別がない)、 Perl(静的型(スカラーとアレイとハッシュは静的に区別される)と型なし(スカラーには型の区別がない)のハイブリット)やTcl(根源的には全て文字列)のような「型なし言語」が生き残っていたが、それらすら、オブジェクト指向の導入などでなんらかの「型」を取り込んでいる。
このようにプログラミング言語の世界では、長い長い時間をかけて苦労して「型なし」を追放してきたのに、 ここでいきなりXMLが「型なし」を復活させてくれているのだ。なんてこった。 XMLはスキーマなしでは、どの属性が数値なのか、どのデータが文字列なのか区別することはできない。 できるのは「ノード」と「テキスト(文字列)」の区別だけだ。
もちろん、XML SchemaやらRELAXやらを導入すれば型の表現はできる。 しかし、「スキーマなしで操作できる」のがXMLの良さではなかったのか。 DOMでデータを取り出してきても、その(型の)解釈は個々のプログラムに任せられてしまう。 要するに、アプリケーションのロジックの中に分散して埋没してしまうということだ。
せめて、古典LispのS式程度(ノード、整数、浮動小数点数、文字列、シンボル)程度の型が、 スキーマなしで表現できれば、こんなことにはならなかったのに。これを濫用といわずして何を。
Sick (YAML for Ruby) の開発者としても知られるwhy the lucky stiffからメールが来た。
全文を引用する。
Hi, matz.
I recently started a Ruby blog which is growing quickly. Lots going on, lots to talk about. However, I'd really like to find a fresh voice from Japan to join in. I think many of us outside of Japan are dying to hear more about what is happening there. And I'm sure many Japanese Rubyists are struggling to get their work translated.
Since you are immersed in the Ruby scene, I'm wondering if you know anyone there who would like to blog in English. I'm looking for someone who can uncover neat software, translate important information from your blog, and perhaps even help us to understand some of the Japanese tech culture.
I think it could be a great opportunity for a Japanese blogger to be heard by an international audience and to make friends outside of Japan.
Thankyou so much, matz. My warmest good luck to you.
_why
要するに、
ということだ。だれか、挑戦する人はいないだろうか？ そんなにいっぱい書く必要もなければ、完璧な英語を使う必要もないと思う。 少々の勇気とちょっとの時間でけっこうなことがなしとげられそうに思うのだが。
いかがでしょう。希望者は私にメールするか、ツッコミで連絡を。
GoogleでのGuido van Rossumの生活の様子。
なかなか楽しそうだ。
いや、でも、フルタイムRubyのためにほぼ自由に使ってもかまわない私の方がもっと恵まれているわけだが。
4774122920
あいかわらず日経Linuxの記事が終わらず悩んでいる。〆切今日なんだけどなあ。
で、あまりに悩んだので、本屋でJavaの本を購入。 買ったのは『4774122920』。 内容よりは水玉蛍之丞のイラスト(とマンガ)が購入の決め手になったのは内緒だ。
言語仕様はともかく、EJBやJBossなどについては無知なので大変参考になった。 またXDocletというコードジェネレーションテクニックを使ったツールがあるということも 名前だけしか知らなかったので勉強になった。
しかし、こんな泥縄の知識に基づいた原稿で読者の皆さんにちょっと申し訳ない気もする。 来月はちゃんとよく知ってるRubyに関連するネタを選ぼう。
しかし、こうやってJavaのプログラムを見ると、 自分でこういうプログラムを開発することを想像するだけで憂鬱になる。 世に入るという「Java好き」の人はこんな冗長性とか気にしないのかな。
裏表紙には「Javaが好きなプログラマだけに本書を勧めます！」とあるので、 私ははなから対象外なのかもしれないけど。
「週末にお願いします」と言われたのだが、 朝の時点でまだ半分も書けていない。 「週末っていつまでだ」とかなり焦りながら 原稿書き。
本当は休日は家族と過ごしたいのだが。 まあ、上二人が部活でいないので、家族全員がそろうわけではないのだが。
ところで、今さらながらJavaScriptって面白い言語だね。 同じ動的言語でもRubyとは姿勢が対極。 簡単な仕組みで中身までさらしていろいろできるようにしたいJavaScriptと、 必要そうな機能は一通り組み込みで持ってしまって、中身は見せずにスマートに書かせたいRuby。
中身が見えてる方が遊ぶ余地は広いけど、どうしても記述は繁雑になる。 中身が見えない方は、言語が許していないことはとたんに難しくなるけど、 その範囲内であれば生産性が高い。
そういう意味ではJavaScriptやPythonの方がLispに近いのかもしれない。 RubyでMOPとかあり得ないものな。
あと、プロトタイプ言語と言いながら、 Ioほど徹底していない(ので、私には使いにくい)オブジェクトシステムにはなんだかなあ。 関数オブジェクトに対するnewとか要らないから直接cloneさせて。
Rubiniusは将来S式を入力に許すかもしれず、
そうなればますます「Acceptable Lisp」の地位を括弧確固としたものにできるかも、という話。
しかし、上述の「中身までいじらせるかどうか」という点が 「ホンモノのLisp」との間の越えられない壁になりそうな。
教会での司会、お話、レッスン、初等協会でのお話、と出番の多い日であった。 疲れた。
家族で定期的に聖書を読んでいる。 教養としてもなかなかだ。
で、我々が朗読している間、 三歳の娘は、自分の聖書を開きつつ、 それらしいことを「読んで」いる。
われらは、しゅに、まじでに(？)、おめぐみを、くださりた
彼女が覚えている「聖書らしい音」を適当につなげているらしい。 なんか人工無脳みたい。 やっぱり、マルコフ連鎖のようなことが脳内で処理されているのだろうか。
合宿と言っても夜はやらないのはいつも通り。
Ruby標準規格原案作成をドライブするため、 WG委員長の中田育男先生にわざわざ松江まで来ていただいて 現時点での草案をレビュー。
わたしよりも「できのよい」人たちがメンバーなので ばりばりと進む。っていうか、まる一日昼食以外はほぼ休憩なしってのは どんだけパワフルなんだと。
しかし、わかっていたことではあるけれど、 Rubyってのは標準規格とかに向いてない言語だとつくづく思う。 こうして規格文書としてまとめていて感じるのは、 重箱の隅のような部分で「やめときゃよかった」と思うようなことが残っていること。
ほんとうに申し訳ない。
標準規格はCRuby(MRI)のサブセットになる予定なので、 おおむねDave Thomasの期待する「Ruby Lite」に近いものになるのではないかと思う。