日経バイトの記事の後半。今回は後半の３分割のうちの最初のものだが、 残りも明日以降順次公開される。 前半のときも書いたけど、正確さよりもノリを重視した文章なので、 あくまでもエンターテイメントとして読んでほしい。
mputさんから。
続く議論が「シフトが入るからストローク数は互角だよね」とか「{}はホームポジションから遠い」とか、いぜんミクロな論点に終始している感じがしてちょっと拍子抜けであります。
えー、わざわざミクロな話をしているのは、 結局「}」も「end」も大差ないことを示して、 最後の「意識のスイッチ」を強調したかったからなんだけどなあ。 伝わらないってことは、失敗だったってことだな。
実は「 Ruby では変数の接頭辞 '@' やブロック変数代入構文の '|' など、他に記号が出現する場所が多いから、ブロックの終わりは '}' ではなく 'end' のほうが、記号とアルファベットの割合がよいのだ」という反論を想定していたのですが、どうやらそういうことを考えて end が採用されてるっていうわけじゃないようですね。
Rubyがendを採用している真の理由は
というものだ。もちろん、意識のスイッチもちょっと考えたけど。
あと、カーソルの移動には
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の良さってのは
からこそ、意識のスイッチに役立つという点にあるのであって、 あまり喧伝して他の言語がどんどん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に憧れていたのもありますが。
昨日からえらい寒くて、大変。雪は積もるし道は凍るし。
私のうちは坂になった路地の奥にあるのだが、道が凍っていて上れない。 スタッドレスがすり減ってるのかな。とりあえず坂の下に駐車させてもらう。 こんなことで明日のデブサミに行けるのか。
ちゅーわけで、出席が危ぶまれていないこともないデブサミですが、 今朝の飛行機は飛んだらしいので、明日も大丈夫だと期待するものです。
食事に参加表明を出してくださる方が複数いらっしゃったので感謝しています。 デブサミに参加される方々は、 私たちのセッションが終わった直後に声をかけてくだされば、そのまま移動できると思います。
参加されない方は...、どうしよう。参加する人にコンタクトを取る？
どなたか会場を決めていただけませんか。 新宿(かずひこくんの宿)または新橋・銀座(私の宿)の近くが希望です。
OSDLがオープンソフト開発を法的に支援する法律センターを設立するという話。
現在OSSにとって必要とされている支援は(経済的な援助を除いては)このようなものではないだろうか。 日本でこのようなものを作ることは可能なのか。
ま、ひとつの時代が終わり、次のステージに移ったということで。
Nokiaの携帯でPythonアプリが動くという話。
こういう点はRuby(やPerl)と比較して明らかにPythonが優れたところだよな。
新言語。オブジェクト指向スクリプト言語なのだそうだが、どこが目新しいかはよくわからない。 ライセンスはGPL。
やっぱり関係者の立食パーティがあるそうです。
実際は私はそれはどうでも良いのですが(かずひこくんは「関係者」ではないし)、 その後、風穴さんから「一緒に食事しないか」と誘われています。 「立食よりマシなものが食べたい」んだそうです。
せっかくだから風穴さんも誘いたいんですが、 デブサミ参加者のみなさん、しばらくなら待てますかね。
ううっ、なにもかもこんなにぎりぎりに話が来なくてもいいのに...。
多数が読んでいる日記でこんなにプライベートな話はどうか、とも思いましたが、 考えてみたら、普段から「私が車をぶつけた」というような思いっきりプライベートな話が満載でした、この「Matzにっき」は。
まとめ記事。でも、「たとえ新規性があっても特許は無効」という意見はないようだ。 私の暴走なのかな。
ところで、2ページ目、
判決を受け、著名なプログラマーが松下製品の不買を表明するなど、開発者サイドにも波紋が広がっている。
の「著名なプログラマー」って、もしかしてもしかすると私のこと？
いや、自意識過剰かな。他にも不買表明した人いそうだものな。
Thinkpad入院中に全文検索データベースを壊してしまった(FAT32ファイルシステムだっ たのがいけなかったのかなぁ)ので、再構築しようと思ったが、 morqにたまった15万通 のメールにインデックスを張ろうとすると、いつまでたっても処理が終わらない。
業を煮やしてRastメーリングリストに流れていた高速化パッチを当てた。すると、今ま で１通の処理に１秒くらいかかる上に、 syncのタイミングで数分から十数分も待たされ ていたのが、１通あたりの処理は数十倍、sync待ち時間を数秒で済むようになった。
すばらしい。
これくらいスケールしないと大量データは扱えないだろう。
あーあ、出ちゃったよ。X41より軽くてX32よりパワフルなのが。
Intel Core Duoだってさ。バッテリーが公称で4.5時間はちょっと短いかも。まあ、実際 にはそんなにバッテリーが必要なことは滅多に無いんだけど。でも、長いと飛行機の中 とかで安心して作業ができるよね。
しかし、今のX31で不満があるわけではないので、後1,2年はこれを愛用しようと思う。 それからその時点での最新あたりを購入すればよいよね。もう、日常生活に必要なCPUパ ワーは余ってるんだよね、きっと。
たぶん、それより前にディスク容量が足りなくなると思うが(今、40Gが80%)、 Thinkpad は簡単にディスク交換できるし。
ここまでCPUが高速になると、これからはCPUパワーを消費するために新しいアプリケー ションが必要になるのではないだろうか。たとえば、全文検索やインデクシング、自然 言語処理などが考えられるけど、本命はそんなに簡単に思いつかないものかもしれない 。
現代の言語屋はもともとCPUをあまり消費しないタイプの人間だしね。
よしおかさんが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
昨年のRubyConfにおけるRejectConfレポート。
体力なくて出席しなかったんだよなあ。 出てればよかったかなあ。
カプコムのMTフレームワークにおける種々の工夫。
っていうか、並列度をあげるための(私の知らない)テクニックの数々。 これって「普通」のコンピューティングには応用できないもんかね。 まあ、日常的なタスクにはそんなに並列度はないか。
どう逆立ちしてもtrunkがYARVであるのは間違いのない事実で、 いつまでもmatzrubyの箱庭で遊んでいても、世間様には貢献できない。
というわけで、意を決してtrunkに手を入れてみる。 あまり難しい(coreに大々的に手を入れる)ようなものは 手に負えなそうなので、とりあえず簡単なものから。
コア以外のソースコードは共通なので、意外と簡単。 で、コミットしてみた。
この後、
も導入しよう。クラスローカルインスタンス変数には 命令の追加が必要になる。ちょっと手ごわい感じ(だけど、動いてるみたい)。
ところで、命令が追加されると tool/compile.rbでダンプされた命令が読み込めなくなるんだけど、 命令セットのバージョンとか付ける必要があるのかな。
Railsが遅いのはGCのせいだ(無駄なオブジェクトを一杯作っている)という話。 また、オブジェクト生成数を削減するmonkey patch付き。
まあ、こういう「発見」は重要で、おそらくは近いうちに Rails本体にも反映されていくんじゃないだろうか。
なお、benchmark.rbへの修正についてはすでにリポジトリにコミットした。
LuaJIT頑張ってます、という話。
YARVによって結構性能が上がったのは事実なんだけど、 正直まだLuaに追いついてないんだよね。 向こうの方がやってることが簡単とか、言い訳はあるんだけど、 言語ユーザーとしてはそんなの関係ないわけで。
JITはまだまだにしても、1.9.0-0ではまだオンにしていない 各種最適化を有効にしたら、どのくらい差が詰まるかな。 まだまだかな。
いずれにしても1.9.0-1では(一時的に多少信頼性が下がっても)最適化を有効にしたい。 そのようにささだくんを説得しよう。
Rubiniusの方が性能面からもテスト充実度からも優れた実装になったら Matzはどうするのか、という話。
別に。
私の最大の関心事は実装ではなく、どのように気分良いプログラミングを実現するか、なので、 それがもっとも簡単に試行錯誤できるのであれば、実装についてはスイッチすることだって ありえる。事実、1.8までの私謹製のインタプリタから1.9ではYARVに移行したわけで。
ただ、現時点では私の意図をもっともよく反映した実装は まだまだC版で、正直Rubiniusに移行する動機づけは不十分である。 まあ、現時点ではそういう働き掛けも受けてないし。
サイトが公開された。プログラムとかはまだ埋まっていない。 あと、３ヶ月ほどなんだけどなあ。
ささだくんも行くみたい。
朝、出かける前に荷物が届いたら、MacBook Proだった。
RubyCentralが「もっとOS Xサポートしっかりしてくれ」ということで、 送ってくれたものだ。Mac所有は初めてのことになる。
で、しばらく使ってみた印象は
であった。なにを言ってるか分からないかもしれないが、もうちょっと詳しく書いてみる。
ハードウェアもソフトウェアもデザインはすばらしい。
なんとなくマニュアルを読まなくても使えるような気分にさせられるし、 実際にかなりのところまで使える。
タッチパッドは思ったよりは良い。二本指によるスクロールは特にすばらしい。 でも、細かいところを狙うのは辛いので、ウィンドウのクローズはちょっと大変。 ショートカットを使うのか。
ずーっと、Unix系OS(特にLinux)で過ごしてきた身としては、 一応Unix系とは言えやはりMacOS Xは違いすぎる。
常識が通用しなくてつらい。これはWindowsでも言えることだけど。
しばらく使っているうちに慣れるだろうか。
いざとなったらソースコードが読めるという安心感がない。
あと、微妙な設定方法がわからない。 たとえば「ことえり」のキーバインディングを、きゅうり改にしたかったらどうしたらよいのか。
あるいは日本語キーボードなのに英語配列にしたければどうすればよいのか。 なかなか難しい。
後者(英語配列)はJANSIという方法でなんとか対応できたけど。
まあ、慣れてない人にとってはLinuxの方が敷居は高いだろうから、 公平な評価とはとても言えないけど。
まあ、一部の期待に反して(？)、日常的にMacBookを使うことはなさそうだなあ。
主要開発者が松江に集合してRuby開発合宿。
うささんは欠席(前日は松江だったのに)。
Redmineのissueをひとつずつ片づける。 だいぶ減った。少なくともアサインされた。
Ruby開発合宿は島根大学の提供でお送りしました。