«前の日(02-01) 最新 次の日(02-03)» 追記

Matzにっき


2004年02月02日

_ [言語]まつもとゆきひろの「プログラミング言語論」【後編】(1)

日経バイトの記事の後半。今回は後半の3分割のうちの最初のものだが、 残りも明日以降順次公開される。 前半のときも書いたけど、正確さよりもノリを重視した文章なので、 あくまでもエンターテイメントとして読んでほしい。

_ [Ruby]endのユーザビリティ(2)

mputさんから。

続く議論が「シフトが入るからストローク数は互角だよね」とか「{}はホームポジションから遠い」とか、いぜんミクロな論点に終始している感じがしてちょっと拍子抜けであります。

えー、わざわざミクロな話をしているのは、 結局「}」も「end」も大差ないことを示して、 最後の「意識のスイッチ」を強調したかったからなんだけどなあ。 伝わらないってことは、失敗だったってことだな。

実は「 Ruby では変数の接頭辞 '@' やブロック変数代入構文の '|' など、他に記号が出現する場所が多いから、ブロックの終わりは '}' ではなく 'end' のほうが、記号とアルファベットの割合がよいのだ」という反論を想定していたのですが、どうやらそういうことを考えて end が採用されてるっていうわけじゃないようですね。

Rubyがendを採用している真の理由は

  • endを使ってもautoindentできるめどが立った(ruby-modeの方が先にできた)
  • begin/rescueやcaseは { } を使うと「美しくない」

というものだ。もちろん、意識のスイッチもちょっと考えたけど。

あと、カーソルの移動には

ESC C-a		ruby-beginning-of-defun
ESC C-e		ruby-end-of-defun
ESC C-p		ruby-beginning-of-block
ESC C-n		ruby-end-of-block
ESC C-f		ruby-forward-sexp
ESC C-b		ruby-backward-sexp

などが役に立つのではないだろうか。カーソルキーでだーっと移動するよりは。

_ [Ruby]endのユーザビリティ(3)

あ、よく考えて見ると、Rubyのendの良さってのは

  • 一見、「}」に比べて生産性が低そう
  • しかし、実際にはほとんど差がない
  • かつ、他の言語があまり採用していない

からこそ、意識のスイッチに役立つという点にあるのであって、 あまり喧伝して他の言語がどんどんendを使うようになっては優位性がなくなるような気がするな。 みなさん、昨日書いたことは忘れてください。

で、begin/rescueやcase での brace はどのへんが美しくないかというと、 randyさんのおっしゃるように

case val {
  when a
  ...
  when b
  ...
  when c
  ...
}

または

try {
  ...
rescue IOError
  ...
rescue SyntaxError
  ...
ensure
  ...
}

のようにブレースの中で区切るのも変だし、とはいえ

case val
when a {
 ...
}
when b {
 ...
}
when c {
 ...
}

あるいは

try {
 ...
}
rescue IOError {
 ...
} 
rescue SyntaxError {
 ...
}

のように細かいブレースの連鎖になるのも気に入らなかったということです。 学生時代にOOSCに影響されてcomb styleに憧れていたのもありますが。


2005年02月02日

_ 気温

昨日からえらい寒くて、大変。雪は積もるし道は凍るし。

私のうちは坂になった路地の奥にあるのだが、道が凍っていて上れない。 スタッドレスがすり減ってるのかな。とりあえず坂の下に駐車させてもらう。 こんなことで明日のデブサミに行けるのか。

_ デブサミ2005

ちゅーわけで、出席が危ぶまれていないこともないデブサミですが、 今朝の飛行機は飛んだらしいので、明日も大丈夫だと期待するものです。

食事に参加表明を出してくださる方が複数いらっしゃったので感謝しています。 デブサミに参加される方々は、 私たちのセッションが終わった直後に声をかけてくだされば、そのまま移動できると思います。

参加されない方は...、どうしよう。参加する人にコンタクトを取る?

どなたか会場を決めていただけませんか。 新宿(かずひこくんの宿)または新橋・銀座(私の宿)の近くが希望です。

_ [OSS] オープンソフト開発支援の法律センター開設

OSDLがオープンソフト開発を法的に支援する法律センターを設立するという話。

現在OSSにとって必要とされている支援は(経済的な援助を除いては)このようなものではないだろうか。 日本でこのようなものを作ることは可能なのか。

_ [OSS] エリック・レイモンド氏がOSI代表を降板

ま、ひとつの時代が終わり、次のステージに移ったということで。

_ [OSS] FSFは将来のGPLに対してフリーハンドか

奥地さんによる的確な指摘。私の与太よりもはるかに価値がある。

これでkazuhoさんの疑念はすべてクリアになったのでは?

_ [言語] Nokia、アプリケーション開発に『Python』言語を追加

Nokiaの携帯でPythonアプリが動くという話。

こういう点はRuby(やPerl)と比較して明らかにPythonが優れたところだよな。

_ [言語] Tao Language for Scripting and Computing

新言語。オブジェクト指向スクリプト言語なのだそうだが、どこが目新しいかはよくわからない。 ライセンスはGPL。

_ デブサミ2005・追記

やっぱり関係者の立食パーティがあるそうです。

実際は私はそれはどうでも良いのですが(かずひこくんは「関係者」ではないし)、 その後、風穴さんから「一緒に食事しないか」と誘われています。 「立食よりマシなものが食べたい」んだそうです。

せっかくだから風穴さんも誘いたいんですが、 デブサミ参加者のみなさん、しばらくなら待てますかね。

ううっ、なにもかもこんなにぎりぎりに話が来なくてもいいのに...。

多数が読んでいる日記でこんなにプライベートな話はどうか、とも思いましたが、 考えてみたら、普段から「私が車をぶつけた」というような思いっきりプライベートな話が満載でした、この「Matzにっき」は。

_ [特許] ITmediaニュース:「一太郎」判決の衝撃

まとめ記事。でも、「たとえ新規性があっても特許は無効」という意見はないようだ。 私の暴走なのかな。

ところで、2ページ目

判決を受け、著名なプログラマーが松下製品の不買を表明するなど、開発者サイドにも波紋が広がっている。

の「著名なプログラマー」って、もしかしてもしかするとのこと?

いや、自意識過剰かな。他にも不買表明した人いそうだものな。


2006年02月02日

_ [OSS] Rast高速化パッチ

Thinkpad入院中に全文検索データベースを壊してしまった(FAT32ファイルシステムだっ たのがいけなかったのかなぁ)ので、再構築しようと思ったが、 morqにたまった15万通 のメールにインデックスを張ろうとすると、いつまでたっても処理が終わらない。

業を煮やしてRastメーリングリストに流れていた高速化パッチを当てた。すると、今ま で1通の処理に1秒くらいかかる上に、 syncのタイミングで数分から十数分も待たされ ていたのが、1通あたりの処理は数十倍、sync待ち時間を数秒で済むようになった。

すばらしい。

これくらいスケールしないと大量データは扱えないだろう。

_ [PC] レノボ、Core Duoを搭載したThinkPad X60 / T60を発表

あーあ、出ちゃったよ。X41より軽くてX32よりパワフルなのが。

Intel Core Duoだってさ。バッテリーが公称で4.5時間はちょっと短いかも。まあ、実際 にはそんなにバッテリーが必要なことは滅多に無いんだけど。でも、長いと飛行機の中 とかで安心して作業ができるよね。

しかし、今のX31で不満があるわけではないので、後1,2年はこれを愛用しようと思う。 それからその時点での最新あたりを購入すればよいよね。もう、日常生活に必要なCPUパ ワーは余ってるんだよね、きっと。

たぶん、それより前にディスク容量が足りなくなると思うが(今、40Gが80%)、 Thinkpad は簡単にディスク交換できるし。

ここまでCPUが高速になると、これからはCPUパワーを消費するために新しいアプリケー ションが必要になるのではないだろうか。たとえば、全文検索やインデクシング、自然 言語処理などが考えられるけど、本命はそんなに簡単に思いつかないものかもしれない 。

現代の言語屋はもともとCPUをあまり消費しないタイプの人間だしね。


2007年02月02日

_ [Ruby] ユメのチカラ: Rubyで習作 添削

よしおかさんがRubyコードを書いてるっ。 私の中で評価が高い人がRubyを使ってるのを見ると、ちょっとうれしい。 増田さんがRuby使いはじめたのを見た時もうれしかったなあ。

で、当の吉岡さんのコードだが、ちょっと冗長な印象がある。 特に三回あるmakehashメソッド呼び出しの周辺がいかにも同じことの繰り返しである。

ここは

  • ハッシュ生成
  • ファイルオープン
  • ファイルのクローズ
  • 例外処理

などをぜんぶmakehashメソッドに詰め込んで、DRYで行こう。 本体部分はよくわからなかったので(手元にデータもないし)、手をつけてない。

で、結果はこんな感じ。テストしてないけど。

#!/usr/bin/env ruby

def makehash(path)
  h = {}
  open(path, "r") do |f|
    f.each do |line|
      line=line.chop
      h[line]=line
    end
  end
  h
rescue
  puts 'error ' + path.to_s
  exit
end

hash1 = makehash(ARGV[0])
hash2 = makehash(ARGV[1])
hash3 = makehash(ARGV[2])

hash1.each do |key, pkg|
  line = pkg.to_s + ', '

  line = line + if pkg == hash2[pkg] 
    "included,     "
  else 
    "not included, "
  end

  line = line + if pkg == hash3[pkg]
    "included\n"
  else
    "not included\n"
  end

  print line
end

_ [Ruby] kiwamu日記 - RubyConf 2006 の裏番組、RejectConf の実施形式メモ

昨年のRubyConfにおけるRejectConfレポート。

体力なくて出席しなかったんだよなあ。 出てればよかったかなあ。

_ 西川善司の3Dゲームファンのための「ロスト プラネット」グラフィックス講座

カプコムのMTフレームワークにおける種々の工夫。

っていうか、並列度をあげるための(私の知らない)テクニックの数々。 これって「普通」のコンピューティングには応用できないもんかね。 まあ、日常的なタスクにはそんなに並列度はないか。

_ [Ruby] YARVに手を入れる

どう逆立ちしてもtrunkがYARVであるのは間違いのない事実で、 いつまでもmatzrubyの箱庭で遊んでいても、世間様には貢献できない。

というわけで、意を決してtrunkに手を入れてみる。 あまり難しい(coreに大々的に手を入れる)ようなものは 手に負えなそうなので、とりあえず簡単なものから。

  • クラス変数の探索順序変更
  • Symbolをふたたびimmediateに

コア以外のソースコードは共通なので、意外と簡単。 で、コミットしてみた。

この後、

  • クラスローカルインスタンス変数
  • ローカル変数スコープの変更

も導入しよう。クラスローカルインスタンス変数には 命令の追加が必要になる。ちょっと手ごわい感じ(だけど、動いてるみたい)。

ところで、命令が追加されると tool/compile.rbでダンプされた命令が読み込めなくなるんだけど、 命令セットのバージョンとか付ける必要があるのかな。


2008年02月02日

_ [Ruby] Nimble Method: Garbage Collection is Why Ruby on Rails is Slow: Patches to Improve Performance 5x; Memory Profiling

Railsが遅いのはGCのせいだ(無駄なオブジェクトを一杯作っている)という話。 また、オブジェクト生成数を削減するmonkey patch付き。

まあ、こういう「発見」は重要で、おそらくは近いうちに Rails本体にも反映されていくんじゃないだろうか。

なお、benchmark.rbへの修正についてはすでにリポジトリにコミットした。

_ [言語] LuaJIT roadmap 2008

LuaJIT頑張ってます、という話。

YARVによって結構性能が上がったのは事実なんだけど、 正直まだLuaに追いついてないんだよね。 向こうの方がやってることが簡単とか、言い訳はあるんだけど、 言語ユーザーとしてはそんなの関係ないわけで。

JITはまだまだにしても、1.9.0-0ではまだオンにしていない 各種最適化を有効にしたら、どのくらい差が詰まるかな。 まだまだかな。

いずれにしても1.9.0-1では(一時的に多少信頼性が下がっても)最適化を有効にしたい。 そのようにささだくんを説得しよう。

_ [Ruby] What will Matz do?

Rubiniusの方が性能面からもテスト充実度からも優れた実装になったら Matzはどうするのか、という話。

別に。

私の最大の関心事は実装ではなく、どのように気分良いプログラミングを実現するか、なので、 それがもっとも簡単に試行錯誤できるのであれば、実装についてはスイッチすることだって ありえる。事実、1.8までの私謹製のインタプリタから1.9ではYARVに移行したわけで。

ただ、現時点では私の意図をもっともよく反映した実装は まだまだC版で、正直Rubiniusに移行する動機づけは不十分である。 まあ、現時点ではそういう働き掛けも受けてないし。

_ [Ruby] EURUKO 2008 − European Ruby Conference, Prague, March 29th − 30th

サイトが公開された。プログラムとかはまだ埋まっていない。 あと、3ヶ月ほどなんだけどなあ。

ささだくんも行くみたい。


2009年02月02日

_ MacBook Pro

朝、出かける前に荷物が届いたら、MacBook Proだった。

RubyCentralが「もっとOS Xサポートしっかりしてくれ」ということで、 送ってくれたものだ。Mac所有は初めてのことになる。

で、しばらく使ってみた印象は

  • わかりやすい
  • わかりにくい
  • わからない

であった。なにを言ってるか分からないかもしれないが、もうちょっと詳しく書いてみる。

わかりやすい

ハードウェアもソフトウェアもデザインはすばらしい。

なんとなくマニュアルを読まなくても使えるような気分にさせられるし、 実際にかなりのところまで使える。

タッチパッドは思ったよりは良い。二本指によるスクロールは特にすばらしい。 でも、細かいところを狙うのは辛いので、ウィンドウのクローズはちょっと大変。 ショートカットを使うのか。

わかりにくい

ずーっと、Unix系OS(特にLinux)で過ごしてきた身としては、 一応Unix系とは言えやはりMacOS Xは違いすぎる。

常識が通用しなくてつらい。これはWindowsでも言えることだけど。

しばらく使っているうちに慣れるだろうか。

わからない

いざとなったらソースコードが読めるという安心感がない。

あと、微妙な設定方法がわからない。 たとえば「ことえり」のキーバインディングを、きゅうり改にしたかったらどうしたらよいのか。

あるいは日本語キーボードなのに英語配列にしたければどうすればよいのか。 なかなか難しい。

後者(英語配列)はJANSIという方法でなんとか対応できたけど。

まあ、慣れてない人にとってはLinuxの方が敷居は高いだろうから、 公平な評価とはとても言えないけど。

まあ、一部の期待に反して(?)、日常的にMacBookを使うことはなさそうだなあ。

_ Ruby開発合宿

主要開発者が松江に集合してRuby開発合宿。

  • matz
  • ko1
  • yugui
  • akr
  • shyouhei
  • shugo
  • knu

うささんは欠席(前日は松江だったのに)。

Redmineのissueをひとつずつ片づける。 だいぶ減った。少なくともアサインされた。

Ruby開発合宿は島根大学の提供でお送りしました。


«前の日(02-01) 最新 次の日(02-03)» 追記