«前の日(01-25) 最新 次の日(01-27)» 追記

Matzにっき


2004年01月26日

_ [OOP]Applying Traits to the Smalltalk Collection Classes

Applying Traits to the Smalltalk Collection Classes,
Andrew P. Black, Nathanael Schärli, Stéphane Ducasse
SIGPLAN Notices Vol.38 No.11, Nov. 2003

読んでみた。suminさんのおっしゃる通り、さほど目新しい印象はなかった。 どうも論文中で触れている"Mix-in"がなにか非常に欠陥のある設計のものをわざわざ取り上げているような 気がする。実際に論文で紹介しているようなクラス階層の再構成はRubyのmoduleを使っても、 ほとんど問題なく行えるような気がする。Rubyにはundefもaliasもあるし。

あと、Rubyだとインスタンス変数の宣言が要らないので、Smalltalkのtraitと違って、 メソッドに対して「they cannot directly reference any instance variable」という制限が必要なくなるということが興味深い。

新しいと感じられた点はtrait同士の演算(sum, overriding, inheritance, excluding)である。 もっとも「overriding」はmoduleに対するinclude、「inheritance」はclassに対するincludeであるから、 Rubyにないのは「sum」と「excluding」だ。これはmoduleに追加するメソッドとして検討の余地はあるかも。 「このモジュールからこれこれのメソッドを除いたもの」とか、 「このモジュールとこのモジュールを足したもの*1」とか、 「このモジュールをこのメソッドの名前だけ変えたもの」とかの指定で、 名前のないtraitが作れるのは非常に面白い。

ただ、traitは「a first-class collection of named methods」であり、 そのinclude(論文中ではuses:)は、そのtraitが(現時点で)持つメソッド集合を使うイメージのようだ。 Rubyのincludeはinheritと同様、 シンボリックな関係*2を維持している。 いっそmoduleもtraitのようにしてしまうとラクなんだが、多分許されないだろうなあ。

moduleとは別にtraitを用意する? それは混乱の元だろう。

*1  衝突したメソッドの呼び出しはエラーになる

*2  includeしたmoduleにメソッドが追加されると追随すること

_ [家族]家庭の夕べ

月曜恒例の「家庭の夕べ」。年初にたてた目標の評価を行う。全然体重減ってないじゃん(苦笑)。

その後、活動として「福笑い」。そしてみんなでアイスクリームを食べる。


2005年01月26日

_ [特許] 米サン、基本ソフト特許1600件を無償公開

分室」からコピー。

今回はNIIKEINET IT newsから。

米サン・マイクロシステムズは25日、高性能コンピューター用の基本ソフト(OS)関連特許1600件を無償公開すると発表した。世界中の技術者に特許を自由に使ってもらい、情報技術(IT)製品・サービスの開発を促し、市場を拡大するのが狙い。

喜ばしいことだが、どのような手続きで公開されるのかをきちんと見極めたい。この記事によれば

専用のホームページを開設、簡単な契約手続きさえすれば、誰でも関連特許を閲覧・利用できる。

ということだが、この「契約」が曲者だ。

追記

つまり、IBM流の「OSD準拠ならOK」という基準ならオープンソース全体に対して益になるが、 下手な制約(たとえばCDDLだけとか、もっと悪いのはOpenSolarisだけが対象とか)がつくと、 益になるどころか害になるケースだって考えられる。公開手段の公表を待ちたい。

追記2

やっぱり「CCDLだけ」だった。ま、どういうふうに使うかはSunの勝手だとは思うけど、インパクトとしても実益としても価値は激減だな。

_ [Ruby]accident attempt

Guido van Rossumによると、 Rubyは「seems like an accident attempt in cleaning up Perl」なんだそうだ。 言ってくれるな。

ま、Guido自身がコメントを出さねばならないほどRubyのプレゼンスが向上したことをすなおに喜ぼう。 それに、こっちも「__typecheck__は良くない」とか書いてるしな。

Guidoって割とRubyに対して警戒心を持っているようで、OSCON 2003でもわざわざRubyトラックにやってきて「Ruby guys misinform about Python」とか発言したらしい。私はその場にいなかったんだけど。

追記

いろんなコメントがついている。 いや、「accident」でも「excellent」でもどっちでもいいんだけどね。


2006年01月26日

_ Thinkpad復活

会社に顔を出すとペリカン便の箱が。

やっと帰ってきたよ、私のThinkpad。

ブートしてみる。いい感じで立ち上がる。 完全復帰。

しかし、この2週間の間のデータやら、 作業やらを移したり復旧させたりするのがそれなりに面倒だ。

一番面倒なのはmorq、もっと具体的にはRastのデータだなあ。 データベース壊しちゃったしなあ。

_ Rastに挑戦?

というわけで、Rast担当者と話をしてみる。

「ちょっと遅いんじゃない?」とか「ちょっとスケーラビリティに欠けるんじゃない?」とか。 身内なのに容赦ないな。いや、「ちょっと」が付いてるぶんだけ優しいのか。

が、彼自身は本業が忙しくて手が出せないらしい。 うーむ。会社としてはお金になる仕事が当然優先だしな。 しかたない。私が手を出すか。 あんまり得意じゃないんだけどな、スピードが要求されるプログラミングは。

しかし、いい話も聞いた。 http://www.j96.org/w3ml/rast-ja/msg/52に投稿されたパッチを使うと(機能制限は出るが)、ずいぶん高速化されるらしい。

今度試してみよう。しかし、自前でRastコンパイルできる環境があったかな。 まず環境整備から始めないと。

_ オープンソースの全文検索エンジンの速度性能比較」のご紹介

今度、情報処理学会の全国大会でこういう発表をします、という話。

5つの主要なオープンソース全文検索エンジン(Namazu, Lucene, Senna, Estraier, Hyper Estraier)について、登録文書数1万件−500万件の範囲での、インデクシング速度および検索速度を測定した結果と、そこから得られた知見を報告します。

だそうです。Rastは仲間に入れてもらえませんよ、ぐすん。

これもスケールしないからだろうか。今後に期待。


2007年01月26日

_ 帰宅

朝起きて、羽田空港へ。

ホテルが南千住だった*1ので、 ほんとうに久しぶりに常磐線に乗った。死ぬほど混んでた。

東京にはひんぱんに行くけど、たいていは混雑する時間を外して活動していたので こんなに人がたくさん乗ってる電車には長らく乗ってなかった。 ちゅーか、9時過ぎてもこれだけ乗ってるってどういうことよ。

東京に住まなくて本当に良かったと思う私。 2便で出雲空港へ。

*1  ぐずぐずしてたら空港に近いホテルは全部満室だった

_ スタイラス紛失

で、うちに帰ったら愛用のVisor Edgeのスタイラスがなくなっていた。 電車の中かどこかで落としたんだろうなあ。 ぐすん。もう、手に入らないだろうなあ。

仕方がないので、以前にいただいていた予備機(あるのかよっ)のスタイラスを使うことにする。

_ 新年会

夜は会社の新年会。昨日はソフトウェアジャパンの懇親会、今日は新年会と 宴会続きすぎ。楽しかったけどね。

_ [言語] SRFI 89: Optional and named parameters

すごい面白い。やっぱLisp(系言語)はアイディアの宝庫だわ。 頭のいい人がいろいろ考えてるからな。

今やってるvisibitilyに結論が出たら次はこれだ(named parameter)と思っているので ぜひ参考にさせてもらおう。

Lispの方には足を向けて寝れない...って、どっちの方角なんだろう?

_ [OSS] O'Reilly Open Source Convention 2007 July 23-27, 2007 Portland, Oregon

今年のOSCONは6月23日から27日。 場所はいつものオレゴンコンベンションセンター。

今年は行かないつもり。呼ばれてないし。

そういえば、RailsConfも 今年はこのオレゴンコンベンションセンターで開催するらしい。 今年はO'Reillyとの共催だからかな。

こちらの日程は5月17日から20日。


2008年01月26日

_ 実家へ

私の両親が1年間の任期で東京での「ボランティア」の途中で 1週間だけ実家に帰ってくるということで、家族総出で米子へ。

昼食をいただいたり、おしゃべりをしたり 大変楽しい時間であった。 途中、私はうとうとしてしまったけど。

_ ひげを剃った

ふと、思い立って髭を剃ってみた。

しかし、家族の誰も気づかない。 夜寝る前になってやっと次女が気づいた。

そんなもんだ。

_ [Ruby] James on Software: Ruby Reddit

私の情報源のひとつ、Redditがsub reddit作成をユーザに開放した ということで、Ruby Redditができた。

他にもHaskellやScalaができてるみたい。

_ [言語] Attacking PHP

PHPがいかに駄目な言語か、という話。

  • いろんなものがfalseだったりするせいで、新たな比較演算子「===」が必要
  • hashやlistがobjectが区別できない
  • オブジェクト指向機能が壊れている
  • lambda(無名関数)がない。create_functionはlambdaじゃない
  • short_open_tagsやらsafe_modeやらregister_globalsがonになってるかもしれない
  • 一貫性のない名前(str_replace,strlen,parse_strとか)
  • 引数の順番がわかりにくい(in_arrayとかstrposとか)
  • strpos('abcd','a')は0を返すが、0は偽である
  • PHPで書かれたたくさんのアプリがあるがどれもHTMLとロジックが分離されてない(本当?)
  • 「PHPは初心者に学びやすい」と言われる。確かにそうかもしれないが、 おかげでどれだけのSQLインジェクションやらXSS脆弱性やら、 ひどいコードが放置されていることか
  • グローバル。使うんじゃないってば。

もちろん、反論もあるだろう。たとえば「Defending PHP」とか。

でも、個人的にはやはり否定側の方が筋が通ってる印象かな。

特に「PHPは初心者に学びやすい(と言われていることが問題である)」という部分に共感する。 PHPは初心者に簡単かもしれないが、初心者による手を抜いたWebアプリケーションは PHPが作られた当初はともかく、現代では害悪ではないだろうか。

Webアプリケーションをなめるな

PHPならではの理由がないわけではないことはわかる。 どこでもインストールされているとか、 デプロイが簡単とか。

でも、「初心者に簡単」を一般公開されるWebアプリケーションを 開発するための言語としての利点にするのはもうやめようよ。

追記

どの言語で書いてもおかしなコードを書く奴は書く」と いう指摘もあった。それは言うまでもない事実ではある。そこには反論しない。

が、本当に問題なのは、世の中には「おかしなコードを書くことを助長する言語」もある という点だ。 で、そういう言語にはおおむね「初心者にやさしい」というラベルがついている。 どういうわけだか。

たぶん、「初心者がおかしなコードを書くのをじゃましない」とか あるいは「初心者っぽいコードを積極的に支援する」から、「初心者に優しい」って呼ばれるんだろう。 もしくは「設計者がまだ初心者」とか。

そういう言語が存在しちゃいけないとは言わないけど(人に迷惑をかけない範囲で)、 ここ半世紀の言語の進化をないがしろにするのはもったいないと思うな。


«前の日(01-25) 最新 次の日(01-27)» 追記