«前の日(01-07) 最新 次の日(01-09)» 追記

Matzにっき


2004年01月08日

_ [生活]出社

会社に行く。当たり前のようだが、生活が崩れ切っているので、久しぶりな気が。

新しい名刺の手配(ちょうど切れてたし、肩書きが微妙に変化したのだ)と、来週の出張のチケットと宿泊の予約。

_ [M17N]Citrus Project

狩野さんのコメントに続き、 曽田さんから丁寧なフォローをいただいた。ありがたいことだ。

いただいた情報に従い調べると、現時点でのCitrusの主眼はiconvの実装と、 wchar_tを用いた処理のようだ。どちらもCSI(Code Set Independent)を目指していて、 興味深い。

今回RubyのM17Nと銘打って実装したい部分は、 「各種エンコーディングを変換することなく行う文字列操作」 なので、直接はオーバーラップしないことも分かった。

ただ、今後文字列のエンコーディング変換についての考察は必須なので、 その際にはCitrus Projectのiconvの実装を{参考にする、取り込ませてもらう}ことにしよう。

_ [テレビ]『FIRE BOYS』

予約しておいたドラマをようやく見る。第一回目。 なんのことはない『め組の大悟』のドラマ化なのだが、面白かった。 なんかドラマを見ようという気になったのは久しぶり。 前回は『サイコドクター』と『アルジャーノンに花束を』だっけか。

要するに原作付きに弱いらしい。

『FIRE BOYS』については、原作から変えてある点がかなりたくさんあったのだが、 それがどれも自然で気にならない。 落合先生が音楽の先生ってことはスマトラ島のエピソードはありえないのねとか、 「めだかヶ」ってことは千石国際空港のネタもなさそうとかは思ったけど。

現場の描写については実際を知らないのでなんともいえないが、嫌な感じは受けなかった。

しかし、毎回火事の撮影ってのはいろんな意味で辛そうだなあ。

追記:

しかし、大悟役の人はもう少し体が大きく見える人のほうがよかったかもしれないなあ。

_ [tDiary]tdiarygrep(3)

「今日のリンク元」を見る限り、最近の私のエントリでもっともヒットしたのはMatz版tdiarygrepらしい。お役に立ててなによりです。

_ [M17N]文字オブジェクト

文字オブジェクトは導入するんでしょうか」とのことだが、 いろいろ考えたあげく、素のRuby M17Nは文字オブジェクトは導入しない。

ともさんが欲しがっている「文字」に対する機能は将来的にもRuby/CHISE(のようなadd-on)が提供するものと考えている。文字に対するrequirementは本当にさまざまなので。それに「文字」そのものが必要なことは意外と少ないものだ。

ただ、Ruby M17Nが提供する「属性」を使った正規表現マッチはできればやりたいと考えているのだが、 ただ、現時点では正規表現の実装をどうするかさえ決めてないので、断言はできない。

あ、そうそう。ともさんのコメントには「文字列を code point の列とする」とありました。 ruby_m17nブランチでは確かにその通りで、コードポイントで文字を近似していました。 今度のM17N化では文字列の内部表現も文字の内部表現もバイト列で、 こうすることで複数のコードポイントから構成される「文字」もちゃんと文字として扱えるようになるはずです。

_ [news]年始、ロボットと愛し合う

新生ITmediaの記事。そういう愛もあるのね...っていうか、そう来るか。爆笑。


2005年01月08日

_ [言語]The Guido van Robot Programming Language

プログラミング言語に人の名前を付けるのは、ひところの流行だったわけだが*1、とうとう、Guido van Rossumの名前をとったものが登場。 名誉なことではないか。

その実体はロボットを操作する教育用言語(Python文法)だそうだ。

*1  だが、RubyはJack RubyやSam Rubyの名前を付けたわけではない

_ [OSS]A New Linux Business Model

オープンソースの問題点として、

  • 適切な報酬の欠如 (Remuneration and Just Rewards)
  • 特許からの保護の欠如 (Patent Protection)
  • 大衆へのアピールの欠如 (Reaching the Masses)

をあげ、それを解決することへのプロポーザル。 基本的には新しいコミュニティを意識した組織を作ることを考えているようなのだが、 それがうまくいくかどうかは、彼ら(amiculus.com)自身も自信がないようだ。

問題の把握は適切だ。が、それを解決するにはもう少し考察が必要な気がする。

_ [言語]Alan Ver0.08

Langsmithメーリングリストで発表された新言語。

ぶちあげたはいいが、なかなか議論が低調なlangsmithメーリングリストから、 最初に登場した言語として注目したい。なにより名前がいいな。絶対重複してそうだけど。

個人的な評価はとりあえず置いておいて、みなさんは、このAlanをどう思いましたか?


2006年01月08日

_ [教会] 断食安息日

先週は第一日曜日だったが、 元旦だったので、今週が断食。

司会だった。

日曜学校は青少年クラスへ。 正規の教師からちゃんと課題が出ていたので、 私は監督するだけ。 みんな真面目にやっていた。

集会後、人を送っていったり、 用事をしたり。

_ あーめん

夕食の祈りの後、 末娘が「あーぺん」とか発声した。

これはきっと「アーメン」と言おうとしたに違いない、 とみんなで大騒ぎした。

親馬鹿。姉馬鹿。兄馬鹿。

_ 筋肉痛・体調不良

雪かきの後遺症か体じゅうがあちこち痛い。

しかし、この節々の痛み方は熱がある時の症状のような気もする。 体もだるいし。


2007年01月08日 成人の日

_ 冬休み最終日

世間的には成人の日で祝日なのだが、 子供たちにとっては冬休み最後の日。 さすがに計画的に宿題はこなしていたようなので パニックに陥ると言うほどではなかったようだが、 それでもやり残しがあったようで(次女は昨日体調が悪くて寝ていたし)、 それなりに頑張っているようだ。

っていうか、うちの子は私の子供時代よりも まじめに宿題とか片付けるよなあ。母親の影響かしら。

私も原稿がいくつも残っているので それにかかりっきり。全然休みではなかった。

全員あまりにこもりっきりだったので、夕食は外食にした。

_ まつもとの弱点

ユーキャンという 通信教育業者がある。

で、新聞にそこの折り込み広告が入っていたわけだが、 妻が「ねえ、こういうのやってみない」という。

妻:「書道とか」
私:「勘弁してくれ」--書道は大の苦手
妻:「ポピュラーピアノとか」
私:「勘弁してくれ」--楽器は大の苦手
子:「ペン習字とか」
私:「だから、勘弁してくれ」--ペン字も苦手

要するに苦手なもののオンパレードであった。

まいった。


2008年01月08日

_ [言語] Substroke Design Dump

前にも書いたような気がするけど、 私は「ビジュアル言語」に対して否定的だ。

ここでいう「ビジュアル言語」とは、 「Microsoft Visual 〜」な言語のことではなくて、 グラフィカルな表現でプログラムを表現しようという試みのこと。 一番成功した(でも、普通の人はやっぱり知らない)のはPrographかなあ。

しかし、もしかしたらこのSubstrokeは意味のある試みかもしれないと思った。

Substrokeは「ビジュアル(画像など目に見えるもの)を操作する言語」だから。

そもそもアルゴリズムという「形のないもの」にむりやり形を与える ビジュアル言語はそれにより想像力を限定してしまうという弱点がある。 また、2次元の表現は1次元の表現よりも高解像度を要求する(ので、一度に視野に入れられる情報量が少ない) のも欠点である。要するにスケールしないのだ。 サンプルでは良くても実用プログラムを書くのは別問題ということ。

しかし、ビジュアルを操作するのであれば、操作するものと表現が一致するわけで、 想像力が限定されるという問題はそもそも発生しない。 むしろ、直接的に操作できるというメリットになる。

とはいえ、ある程度以上複雑な「プログラム」には やはりアルゴリズムやプロセスなど「目に見えない部分」が入り込んでくることは 避けられないわけで、そこをこの「ビジュアル言語」がどう避けるか、 というのは興味がある。

_ [言語] A programming language cannot be better without being unintuitive

「プログラムはわかりにくさがあるくらいでなければ良いものではない」という話。 Rubyのモットー(と呼ばれていた)「Principle of Least Surprise」の真逆であるが。

まずは、Scalaのプログラムから。

(0/:l)(_+_)

なんか、私がメールのシグネチャにつけている似顔絵(と呼べるのか)であるところの 「/:|)」に似ているような気もするけど、これは立派なScalaのプログラムである。

これをもって「だからScalaはダメなんだ」という結論を出すのは早急すぎる。 これらは確かにわざわざわかりにくく書いてはあるけど、個別の文法要素は 決して悪いものではない。むしろ、少々びっくりするくらいでないと本当に良い言語ではないのだ。

なぜか。

仮に「Principle of Least Surprise」を完全に満たす言語があったとすると それはどんな言語であるか、ということを考えると、 結局は「慣れ親しんだ言語と同じ」という結論がでる。 つまり、言語による驚きを最小にするためには新しい言語を学ばなければよいのだ。

しかし、実際には新しい何かを達成するために新しい言語は次々と生まれる。 その「新しい何か」を達成する部分は、誰も知らないのでそれを学ぶ人には 目新しく、驚きの源になるに違いない。

驚きもないような言語は学ぶ価値もない。

もっとも、言語設計には「不必要な驚き」とか、「新しすぎて受け入れられない言語」とかも 存在するので、結局はバランスなわけなのだが。

時間に余裕のある人はJef Raskin on "Intuitive Interfaces"も参照のこと。

_ [OSS] McAfee throws some FUD at the GPL - The INQUIRER

McAfeeがGPLに対するFUDを行ったという話。

In its annual report, Windows security software vendor McAfee told its investors that open source software licence terms it vaguely characterised as " ambiguous" might "result in unanticipated obligations regarding our products."

投資家に対する年次報告においてMcAfeeは以下のように報告した。 「オープンソースソフトウェアの曖昧な性質によって、我々のプロダクトに予期しない義務が発生する可能性がある」

"To the extent that we use 'open source' software, we face risks," McAfee stated.

「オープンソースソフトウェアの利用によって、我々はリスクに直面している」

裏は取っていないけど、これが真実であるとしたら、かなりひどい話。 McAfeeに対して不買運動を始めたくなるくらい。もっとも、もともとMcAfee製品なんて使ってないか。

この記事では、McAfeeの真の動機は、 オープンソースソフトウェア(特にLinux)の台頭により、 (McAfeeがビジネス的に依存している)Windowsの没落することに危機感を覚えたのではないかと 推測している。

確かに、Linuxではウィルスなどの危険性はWindowsよりずっとマシだし(ない、とは言わない)、 そうなればMcAfeeのビジネス規模は相当縮小するだろうな。


2009年01月08日

_ 朝ご飯

今日から子供たちは学校。

寝坊して一緒に朝食を食べれなかった。残念。

_ 恐竜の映画

妻が末娘に「お兄ちゃんが帰ってきたら恐竜の映画を見ようね」と 話しかけていた。

しかし、先日レンタルで借りた「恐竜の映画」は『ジュラシック・パーク』のような。子供が泣き出してしまうんじゃないか。


«前の日(01-07) 最新 次の日(01-09)» 追記