Matzにっき

_ [Ruby] 楽天技術研究所フェロー就任の影響

朝食前に新聞を開いて驚愕した。

昨日プレスリリースされた私のフェロー就任が 地方経済面に掲載されていたからである。 しかも、公表していない「月一回東京」なんてことまで載ってる。 どこで調べたんだ。

この辺が島根クオリティか(ほめてる)。

_ [知財] 私的録音録画小委員会、CD売上減と私的複製の関係めぐり議論は平行線

端から見てると既得権益者が、いかに自分の権益を守り消費者から金を搾り取るか、 という話にしか見えないのが悲しい。それは私がひねくれているから？

_ [Ruby] 川o・-・）＜2nd life - Ruby で debug する7つの方法

• p
• pp
• y
• backtrace (caller)
• set_trace_func
• logger
• profiler

まあ、あとdebuggerもあるにはあるんだけど。一応スレッド対応だったりもするんだけど。

_ [Ruby] Rails vs Django: a non biased yet useless comparison

RailsとDjangoの比較。タイトルにもあるように公平であることを心がけた比較。 結果として、ここはRailsがよい、ここはDjangoがよい、とかいう結論なんだけど。

ただ、Djangoがよい、という点のほとんどはRailsプラグインで解決できる(できてる)と思う。 「最初から付いてるほうがいい(I wish rails had more batteries included)」ということだ そうだけど。

あと、またUnicodeサポートについて言われてる。 確かにRuby 1.8のUnicodeサポートは限定的だ。

が、正直、Railsの国際化という点で問題はさほど起きていないわけだし、 さらに言えば、Perlのutf8フラグ問題とか、Pythonのstrとunicodeの区別とかで 発生する問題に比べたら、1.8のシンプルな解法の方がマシな気がする(のは、作者の欲目か)。

_ [OSS] Dave Gilbert's Weblog : The Badness of JFree

JFreeChartの作者が サンプルコードとドキュメントを有償化したら「そんなのOSSじゃない」と文句を言われた、 という話。

こういう「金を出さないが文句は言う」人たちの話を聞くと悲しくなる。 いいじゃん、別に。ソースについては間違いなくフリー(自由)なんだから。

それ以上のものを求める人がドキュメントとサンプルにお金を払うか、 それだったらJFreeChartは使わない、とするか、 それもまた自由だ。

ドキュメントの有償化は「使ってもらってなんぼ」という傾向のあるOSSにおいて 賢明な選択ではないかもしれないが、絶対にうまくいかないというわけでもないし、 生活の安定に寄与したいからという理由で、ある開発者がそのような選択をするのであれば、 私自身は尊重したい(でも、たぶんドキュメントは買わないけど)。

_ [OSS] Trust, But Verify - O'Reilly ONLamp Blog

レグレッションテスト重要、という話。

Perlのテストスイートは言語本体だけで64793あるのに対して、 Rubyは867しかないという指摘も。うぅ。少しずつ増やしてるんだけどねえ。

_ [言語] Scala Actors -- A Short Tutorial

JVM上のオブジェクト指向関数型言語ScalaにおけるActorの使い方。

よく見ると(よく見なくても)Erlangにそっくり。 あと、RubyのブロックっぽいScalaの文法も気持ちいい。

ScalaのActorはJVMのスレッドプールを使って実現されているそうだけど、 十分な性能が出るなら(これが難しい)、ErlangではなくScalaが次世代を席巻するかも。

Rubyでも、通信できるデータを

• 数値、文字列、シンボル、プロセス(Actor)
• あるいはそれらだけを含む配列、ハッシュ

に限定し、値渡しであることを明記したら、 似たようなActorを実装できるかもしれない。 情報の共有が最低限にできるので、プロセスでもスレッドでも、 あまり問題を起こさず動作するのではないか。

_ [Ruby] taw's blog: Why RLisp will not support Ruby class variables

RubyのセマンティクスにLispの文法を持つ言語RLispがなぜクラス変数をサポートしないか、 という話。

要するに

• ちょっと変(1.8)
• まだ変(1.9)
• 互換性ないし

ということ。1.9のクラス変数の挙動について(手遅れになる前に)見直すべきか。

_ 小野和俊のブログ:梅田望夫氏が言うように、好きなことを貫いて仕事にしていくためにはどのようにすればよいのか

• 交換不可能な能力に磨きをかける
• 「してはいけない」ことに縛られない

だそうだ。

たぶん私は、私の直接知っている人の中で一番「好きなことを貫いて仕事にしている」人だと 自分でも思うが、確かに「Rubyのまつもと」は他の人では交換不可能だし、 結構縛られないで自由に生きているような気がする。服装とか。

もっとも、あんまり縛られないと社会人として(というか、人類として)失格してしまうのだが、 その辺は私よりもずっと「常識人」である妻がサポートしてくれている。 あと、私の場合、宗教上の戒律も、ある一定の範囲以上踏み外さないために役立ってるような気がする。

で、私から付け加えるとするならば、

• 独自の価値観を持つ

  「お金が一番」という価値観を否定まではしないが、私自身はそのようには考えていない。 「効率が一番」という価値観を否定しないが、プログラミング以外の領域ではそのようには考えない。 自分の価値観を自覚することが重要だと思う。 私の場合は「自由」と「幸福」かなあ。

• 自分が価値を見いだしたことへの努力を惜しまない

  たぶん、サッカー選手になるような人は自分の人生の相当の時間をサッカーに費やしているに違いないと思う。私もRuby(とプログラミング)に費やした時間は測りしれない。

くらいかなあ。

_ Q:交換不可能な能力に磨きをかけるに何をすべきか？ A:blogを書けばいいと思うよ - 一人シリコンバレー男

昨日の「交換不可能な能力に磨きをかける」というエントリに対して、どうすれば良いかという答え(の一例)

「ブログを書く」というのはなかなか面白いアプローチだと思う。

最近入手した某資料によると、 「普通のプログラマ(アンケートからの平均)」と 「天才プログラマ(いわゆる「未踏スークリ」クラス)」との違いは、 環境とか学習方法とか学歴とかじゃなくて、 コミュニティとの関りなんだそうだ。 積極的に外に出ていくかどうか。

興味深い。

ブログというのも一種のコミュニティ(ブロゴスフィアって言うの？)へのかかわりだよね。

コミュニティへのかかわりといえば、 オープンソースプロジェクトに参加する、 もっと良いのは自分のオープンソースプロジェクトを立ち上げる(で、それを成功まで持っていく)というのは、もっとも良い「交換不可能な能力に磨きをかける」方法じゃないかという気がした。

実際、私もそうしたわけだし。

_ [知財] 林檎の歌 アップルが「文化庁は著作権行政から手を引け」と主張

Appleがかなり強い口調で文化庁の施策を批判。 もっと言ってやって。

_ [教会] 忘れ物

二台の車に分乗して教会に向かっていたら 途中で電話が鳴った。次女からだ。

「？」と思ってると「うちに他に誰もいない」とのこと。 どうやら置き去りにされたらしい。

後でよくよく話を聞くと、いろいろと不幸な偶然が重なったらしい。

• 次女は探し物があるので二階に上がっていた
• 妻は出かける私に「次女は乗ってるの？」と尋ねた
• 車内からは聞こえなかったので「いってらっしゃい」と言われたつもりで、 「うん、いってくるよ」とうなずいた
• 長女が「次女はお父さんの車に乗ってる(と思う)よ」と発言した
• 妻は夫と長女の言葉(？)を信じてそのまま出発
• 誰もいないことに気がついた次女は母親のPHSに電話をかけた
• そしたらすぐそばのカバンから着信音が
• しかたがないのでお父さんに連絡
• 次女を迎えに引き返す

おかげで遅刻しちゃったよ。 誰が悪いって、誰も悪くないよねえ。

_ [原稿] 日経Linux 2007年8月号

もう8月号だってさ。

今月のテーマは「文字コード」。 各種文字集合(JIS X 0201とか0208とかUnicodeとか)や それぞれの符号化方式などについてまとめる予定。

でも、ちょっと進みが遅くて〆切(5日)には間に合いそうにない。 あらかじめ「ちょっと遅れます」と連絡しておく。

_ [言語] Converge

新言語。

• Pythonのインデントブロック
• IconのSuccess/Failureベース評価
• コンパイル時メタプログラミング(マクロっぽい)

が特徴。なんていうか、なんだ、自分の好きな機能をぶちこんだ言語 という意味では極めて正統的な「俺言語」だと思う。 広く使われるかどうかは別として。

_ [Ruby] the Minnu's Filer2

Rubyを組み込んだファイラーソフトウェア。

コマンドラインのシェル操作が体の一部になってる私は いわゆるファイラーを日常的に使ったことがないのだが、 これはその辺のファイラーをいろんな意味で凌駕している。

こんな方に向いてます、だそうだ。

1. PC-UNIXを最近始めてシェルを使いはじめたが、どうも肌に合わない。特にファイルのコピーや移動のコマンドを入力するのがめんどくさい。
2. シェルで処理するよりスクリプト(Ruby)で処理する方が好きだ。
3. マウスよりキーボードが好き。
4. ファイル名に漢字ファイル名を使っている。
5. 任意のファイルを選択してから、そのファイルに対する処理を行うスクリプトを書きたい。
6. システム管理者で楽に設定ファイルを弄りたい。
7. IDEよりファイラ＋エディッタ＋コンパイラ+コマンドラインツールなど単機能なツールを組み合わせて開発する方が好きだ。特に開発ツールはsshでログインしたときも利用でき動作が軽快な端末上のツールで固めたい。

要するにファイルへの操作のシェルコマンド部分をRubyで書けちゃう ということらしい。また、メニューから一通りの操作もできるみたい。

好みが極端に別れそうなソフトウェアだ。こういうアプローチのものは好きだな。

_ 地方格差をなくすためにみんなでwebでがんばろうじゃ駄目な理由を考える - 一人シリコンバレー男

webビジネス（モバイルコンテンツも含む）は、 地方での経済振興に役に立つと考えます。

理由は三点

1. 場所による利益の機械損失が少ない （渋谷で開発しようが、鎌倉で開発しようができたものを発信する場所は一緒）
2. 大規模な施設を必要としない （製造業と違い工場のような初期投資の大きい大規模施設を必要としない）
3. ナレッジを学びやすい環境が整っている （リファレンスはオンラインに大量にあり、わからなければ「はてな」「教えてgoo」へどうぞ）

しかし、筆者はそれだけでは「webビジネスが地方の経済振興の鍵へとならない」と主張する。 なぜかと言うと「やはり「世界とビジネスをする」といった意識が不足している」からだと。

いや、どうなんだろう。確かに松江とかも上記の理由で地域振興しようとしているのだが、 やはりいろいろと課題もあるわけで。島根県と提携しているテキサス州となんかしよう という話はあるらしいので、まったく「世界とビジネスする」視点がないわけじゃないようだけど。

_ [言語] Lightweight Language Spirit

LL魂のチケット発売開始。

例年の「Language Update」と「オレ様言語の作りかた」のコーディネータを依頼されている。 しかし、別件とコンフリクトしてるんだよなあ。 どっちを選ぶか。

_ Geekなぺーじ：選択肢を減らすことの重要性

「選択肢が多い方がよい」というのは自明のような気がするが 実はそうではない、という話。

• 選択肢の多さは機能麻痺(Paralysis)を引き起こす
• 最悪の選択を誘発する
• 満足度が低くなる

選択肢はいつもいつも良いものであるとは限らないということ。

我田引水すれば、もっとも選択肢の多い(自由度の多い)言語が ユーザ満足度が高いとは限らないということでもある。

デザインする人はこころしなければならない原則。

_ [言語] RubyよりPHPを好む初心者

以下のようなコメントをいただいた。

公式サイトをたずねて20分でHello World的なWebアプリを書けるようにならない限り、RubyやPythonが初心者にPHPより好まれることはないでしょう。

Rubyの公式サイトは(というか、Rubyそのものが)Webアプリケーション作成に特化していないので、 ２０分でHello World的Webページを作るのはちょっとしんどいかもしれない。 そのことは認める。PHPで２０分でできるかどうかは知らないが、 HTMLに数行のコードをたすようなものであれば、 Rubyよりも簡単であろうことは想像できる。

が、20分で作る「Hello World的動的Webページ」はともかく、 「ちゃんとしたWebアプリケーション」を作成するのは、 そんなに簡単なことではないのではないか。 そんなに簡単に手を出してはいけないことなのではないか。

「初心者にもWebアプリケーションが書ける」という幻想を与えることで、 バグだらけで、メンテナンス性が低く、セキュリティ問題を抱えた Webアプリケーションを乱造することになっているのではないだろうか。

ここでは、PHPで「ちゃんとしたWebアプリケーションが書けない」と言ってるわけではない。 しかし、ちゃんとしたアプリケーション開発には、 PHPだろうがなんだろうがそれなりの知識や仕組みやフレームワークが必要で、 20分で作るHello World的動的Webページの延長線上にはない、と思う。

本当は難しいことを簡単にできるように思わせるのはかえって罪のような気がする。

参考: Teach Yourself Programming in Ten Years

追記

PHPを「けなしている」と見られるのは別に構わないのだが、 「Rubyの宣伝をしている」と言われたのは心外であった。 「どこがそういう風に読めたかな」と考えてみると タイトルに「Rubyより」と書いてあるのが、 「Rubyの方がいいのに」と思っているように伝わったのかもしれない。 ということで、Strike out。

で、念のため以下を明記しておく

書いてないこと

• PHPではセキュアなアプリは書けない
• PHPは初心者がプログラミングを学ぶのに向いていない
• Rubyの方がPHPより優れている

書きたかったこと

• セキュアでないWebアプリは害悪である
  • Webアプリである以上、公開するなというわけにはいかないだろう
• PHPでも(Rubyでも)セキュアなWebアプリを作るのはそれなりに大変
• ということは、Webアプリは初心者に向かないテーマだろう
• 簡単に(比較的)セキュアなWebアプリが作れるプラットフォームはありえる
• が、少なくとも素のPHPはそうじゃない
• その点、なんらかのフレームワークを使ったものはもうちょっとマシ
• だけど、それならどの言語でも似たようなもので、初心者に対するPHPの優位性ってのは幻想だよね
• 結論: 初心者はWebアプリに手を出さない方がよい。少なくとも素のPHPは危険

_ [Ruby] CodeGear、Ruby統合開発環境の詳細を明らかに − ＠IT

というわけで、朝から東京へ。 空港までの道がおもったよりも混んでいてちょとあせる。 とはいえ、ぶじに時間までに渋谷セルリアンタワー(Googleオフィスがあるとこ)まで。

で、いろいろな人とあいさつした後、 Ruby IDE発表セッションの一番最後にご挨拶。 特に段取りとかも決めてなかったので、なんかぐだぐだな感じで 思ってることを伝えたり。まあ、IDEとしては良く頑張ってると思う。 RadRailsに似てるけど、直接コンソールにタイプできたり、 より上級者も意識してる感じか。

その後、 CodeGearで今回のRuby IDEの後ろにいる人、 David I. ことDavid IntersimoneとShelby Sandersと昼食。 四川料理。大変おいしかった。苦手なセロリ以外は。

で、CodeGear(Borland)における言語開発環境とか、 issue trackingとかについていろいろと興味深い話をした。 個人的にはRubyそのものの開発で一番改善の余地があるのが このissue trackingだと思うので(trac入れれば解決、というわけでもなさそうだし)、 いろいろと参考になった。

それ、Railsで作れば、と言われそうだなあ。

Shelbyとはその後、Ruby IDEに関してちょっと話をした。 これはEclipseのサブセットの上に構築されていて、 その点ではRadRailsに似ているのだそうだ。 だからIDE自身はJavaで開発されているとのこと。

RadRailsは個人プロジェクトで継続性に不安があり、 ビジネスレベルに届くかどうかわからなかったので自分たちでIDEを作ることにしたとのこと。 実際、RadRailsはAptanaに買われちゃったし。 「AptanaはRubyというよりもWeb2.0にフォーカスしており、 正直なんでRadRailsに投資したのかわからない」とShelbyは言っていた。 「が、我々は敵対するつもりはなく、状況が許せば協調したい。 実際にEclipseなどにすでにcontributeしてるよ」とのことであった。

このRuby IDEが具体的にいつ登場するのか、価格はいくらになるのか、などは まだ未定とのこと。登場は「今年後半」としか決まってないらしい。

だが、少なくともCodeGearはRubyに対して本気であり、 決して道楽というわけではなく、ビジネスとして軌道を乗せる熱意があることは David I.やShelbyと話をしてて強く感じた。

いろいろためになるイベントであった。

• Matz：コード補完を実現しているのがすごい--CodeGear Ruby IDE - ZDNet Japan
• デベロッパーキャンプ、会場より - Allegro Barbaro [ITmedia オルタナティブ・ブログ]

_ [Ruby] CodeZine：RailsでWikiシステムを作成する（Wiki, Ruby on Rails）

Railsで作るWiki。ActiveRecordを使わずに ファイルベースでモデルを作ってるところがちょっと珍しいか。

_ [言語] C[omp]UTE: Lessons Learned with Erlang

Erlangで「並列数独ソルバー」を開発した経験から学んだこと。

「Rubyにはtail call optimizationがないから、状態機械の各状態を関数に変換することに抵抗がある」という指摘がある。実はYARVにはささだくんがtail callを直すコードは入れてくれているのだが、デフォルトではオンになっていない。ここにオンにした方が良い理由はひとつ。

Erlangっぽい並列ライブラリへのニーズはそれなりに高そうだ。 Multi-VMを使うのか、Multi-Process＋プロセス間通信を使うのかは別として。

_ [Ruby] murphee's Rant - Ruby native threads vs. lightweight processes

マルチコア利用はプロセスでいいかも、という話なのだが、 コメント欄に驚異的な情報が。

Evan Phoenix, who's leading the Rubinius alternative Ruby implementation project, recently indicated that his green threading system carries extremely low per thread/process overhead (~8 bytes, IIRC). Not to put words in Evan's mouth, but he seemed interested in a scenario similar to the one you describe, in which Ruby's threading model looks more like Erlang's, and the cost of running many small concurrent processes is minimal. Keep your eyes on Rubinius!

1スレッドあたり8バイト以下、とな！ Rubinius恐るべし。

_ 経営者倶楽部 - 2011年、テレビが消える

そーだよなあ。後4年で日本全国のすべてのテレビが使えなくなるという事実を ちゃんと認識していない人の方がはるかに多いよなあ。

どうすんだろ。

_ うっかり

会場から羽田へ向かう京急に乗っていたら、気がついたら天空橋を京急蒲田に向かっていた。 どうやら、うとうとしている間に電車が羽田空港を出発してしまったらしい。 しかも、そういう時に限って快速で空港線の途中の駅に止まらないし。

すごい、あせった。

が、蒲田から引き返しても飛行機には間に合った。 ちゃんと余裕をもって行動しといてよかった。

_ お客さん

RubyとOSS関連のビジネスの話のために お客さんが松江まで来てくださる。 最近、わざわざ松江まで足を運んでくださる方が増えて 申し訳ないくらいだ。

で、大変有意義な話がたくさんできたのだが、 やはりOSSでオリジナルなビジネスとなるといろいろと課題が大きいことも 改めて感じた。もっとも、類似物がないビジネスがいつも必要なわけではなくて、 似たものがあっても十分な差別化が行えればそれでいいんだけれども。

_ うっかり(2)

で、夜、一緒に食事をしましょう、という話になって、 駅前から車を移動させようと思ったら脱輪した(ぐすん)。

同僚に助けてもらってなんとか脱出できた。 みなさん、ありがとう。おかげで助かったよ。

食事は岩ガキなど海産物を中心に。 大変おいしかった。

_ moratorium | libaio(Linuxの非同期I/Oライブラリ)の使い方

非同期ライブラリを使うことでデータ処理能力が向上する という話。

意外と簡単な気がしたが、やはりCプログラミングは繁雑だ。 Rubyインタフェースを用意すると楽できるかなあ。

「トータルの性能」を考えるとRubyの選択には難しい判断を迫られるが。

_ [言語] Advanced Topics in Programming Languages: Concurrency/message passing Newsqueak - Google Video

Newsqueakといっても、「新しいSqueak」ではない。 InfernoのLimboに受け継がれた並列プログラミング言語である。

全編英語なので(当たり前)、ちょっとしんどいが、 スライドを見てるだけで雰囲気はわかる。

やっぱ、こういうメッセージパッシングモデルが、 これからの並列モデルが進む道なんだろうか。

最後の勝者が ErlangかScalaか、はたまた既存の言語にメッセージパッシングを加えたものかは わからないけど。

_ うっかり(3)

目が覚めたら6時14分で、とっくにセミナリーの時間になっている。 やっちまった。

教会に着いたら、みんなまだ待っててくれてる。 雨降りじゃなかったのがせめてもの救いだ。

みんな、ごめんね、もう遅刻しないから。

しかし、ここのところ「うっかり」が多すぎる。 疲れてるのか？

そうなのか？

_ [言語] The Hand of FuManChu - Python concurrency syntax

並列プログラミングの的敵は共有データであり、 それをPythonから取り除くにはどうしたらいいのか という思考実験。

とりあえず、classとmodule(の中身)をimmutableにすることと、 mutableなattributeに@sharedというannotationを付けることを提案している。

が、共有される状態を取り除くためには、 そんな些細な変更ではダメだと思うな。 それこそ言語が違ってしまうくらいの変更を加えるか、 プロセス(or スレッド or ファイバ)を なんらかの「越えられない壁」で区切ってしまうしかないような気がする。

_ 「中毒性」ある受託開発がソフトウェアベンチャーの躍進を阻む - 大迫正治 REPEDANT BLOG [ITmedia オルタナティブ・ブログ]

確かに。

まあ、受託なんてやってる会社は 少なくとも「ベンチャー」ではないよな。NaClも含めて。 全然冒険してないもの。

まあ、私は冒険好きじゃないんで、それはそれで望むところではあるんだけど。 でも、そろそろ受託じゃない自前のサービス提供するようなこともやってみたい気がする。 お客さんの都合に振り回されない事業も必要だと思うし。

_ [言語] Paul Buchheit: Java running faster than C

昔は「Javaなんて遅くて使えない」なんて評価が目立ったけど、 今じゃ下手するとJavaの方がCよりも速いことがあるよね、という話。

興味深かったのがここ。

Compiled JS is about 9x slower than C on this test. If CPU speed doubles every 18 months, then JS in 2007 performs like C in 2002.

コンパイルされたJavaScriptはCの9倍遅い。 もし、CPU速度が18ヶ月で倍になるのだとすれば、 2007年のJavaScriptは2002のCと同程度に速い

そうなのか。ハードウェアの進歩は恐るべし。

_ へ〜たのめも:Google のソフトウェア・エンジニアリング - livedoor Blog（ブログ）

Google Developer Dayの鵜飼さんのセッションのログ。

徹底した開発体制は参考になる。 うちにもずいぶん改善の余地はありそうな。

もちろんRubyの開発体制も。

_ 業務・システムの視点が欠落した「年金記録漏れ」問題の与野党議論 ビジネス-最新ニュース:IT-PLUS

普通に考えたら、この種のデータ1500万件を 1年間で処理するのは絶対に無理だと思うんだけど。 「政治生命を賭ける」んだよね。私なら絶対にやらない。

どうやって「なあなあ」に済ませる気だろう。 むしろその辺の政治的手腕に注目したい。 きっと、みんなに忘れてもらうようにマスコミを誘導するんだろうな。

_ 404 Blog Not Found:好きを仕事にするな、仕事を好きにしてしまえ

先日の「好きを貫くためには」というエントリに対する 弾さんの反応。

「仕事を好きにしてしまえ」という発想はとても健全だと思う。 少なくとも「好きを仕事にする」ことを目標とするよりは。

「好きを仕事にする」ことを目標として選ぶのは大変危険で、 「今ここにいる自分以外の『本当の自分』を求める」ことにつながる。

「本当の自分探し」ほど不毛なものはない。 そんな自分は存在しないからだ。

ある意味、新規蒔き直したい症候群にもつながる。 そんなのうまく行くわけはない。

なすべきは「継続的な変化」である。 自分の今ある位置から、より快適な方向へ少しでも変化するように 継続的に環境に働きかけ、より快適な環境、より好きなことがたくさんできる環境を 勝ち取ることができるようにすることこそが進むべき道であろう。

「青い鳥」はどこにもいない。 「本当の自分」もどこにもいない。

「好きを仕事にする」のは目標であってはならない。 それはあくまでも「結果」である。

_ [言語] real tangible >> Announcing HQNSFPL9+, the one true successor to HQ9+

究極シンプル言語HQ9+の後継言語HQNSFPL9+。

HQ9+の持つ以下の機能に加えて、

• ‘h’ prints Hello World!
• ‘q’ prints a quine, i.e. the source of the executing program
• ‘9′ prints 99 bottles of beer on the wall
• ‘+’ increments the accumulator

さらに以下の機能が増えている。

• ‘n’ solves the Towers of Hanoi problem with n disks, where n is the value of the accumulator. It also resets the accumulator.
• ’s’ solves a sudoku, input to stdin as 9 lines of text consisting of digits 0-9.
• ‘f’ prints the nth Fibonacci number, where n is the accumulator. It also resets the accumulator.
• ‘p’ solves the halting problem on this program. It prints Yes if the program halts, and No otherwise.
• ‘l’ infinitely loops the program. I mean I had to make ‘p’ more interesting.

だからなに？ と言われそうだが。

_ [Ruby] Why are there no Ruby jobs? - O'Reilly Ruby

Railsの仕事や求人は増えているが、 Railsから離れたRuby単体の仕事はどうだろうか。まだまだのように思える、という話。

まあ、私がそれを望んでいるかどうかは別として、 それは事実としてあると思う。RubyKaigiのキーノートで使わせてもらおうかな。

_ [Ruby] Dive into Erlang - Is DHH right about concurrency?

DHHが

Multiple cores are laughably easy to utilize for web applications because our problems are rarely in the speed of serving 1 request.

といったがそれは事実か、という話。

まあ、DHHが話題にするRailsがカバーする領域では これは事実だと思う。が、それを必要以上に一般化して反論するのはどうかと思う。

が、反論の内容は以下の通り。

• CPU intensive requestsでは1requestの時間が問題になることは実際にある (そりゃそうだろう)
• リアルワールドアプリではRailsは1プロセスあたり200MBメモリを消費することは珍しくない。それはメモり使いすぎ (そうなの？)

で、ここで「しかし、Erlangなら」と続くわけだが、 まあ、いいや。

CPU intensive requestsならAP4RやdRubyを活用する手もあるし、 メモリについてもいろいろと手は打てると思う。

_ [Ruby] 合宿

ささだくんのオフィスで開発合宿。

出席者は

• akrさん
• moriqさん
• nokadaさん
• ko1さん
• mputさん
• usaさん
• matz

1.9の文法からm17nまで幅広い領域で議論が行われた。 特にlambdaとbreak/nextについては、ちゃんと明確化ができたと思う。

_ [Ruby] RubyKaigi前夜祭

御茶ノ水で。

いろんな人と話をして楽しかった。 私が着ていった「Python Cookbook T-shirt」は あちこちでウケていた。 私、Pythonファンですから。

Dave Thomas, Tim Brayとも話をした。 元気そう。あまり時差ぼけとか感じてないように見えたけど。

_ zshに移行

合宿中の会話にモチベートされたので、 長らく使い続けてきたbashからzshに移行してみた。

思ったよりもはるかに簡単に移行できたので拍子抜けしてしまった。 愛用のbashrcもほぼそのままzshrcに移動できたし。

ただ、bashでは可能であったワードの途中でのコンプリーションが できないようなのがちょっと面倒。zshのことだからカスタマイズ次第で できそうな気もするのだが、設定項目が見つけられない。

_ メール事故

どうやら、 先日、Outbound Port 25 Blocking対応をした時に、 なにか設定に問題があって、配送サーバによっては 私からのメールが不正なメールとしてはねられているようだ。

具体的には日経BPなどにメールが届かない。

私自身と家族のところには届くので気付くのが遅れてしまった。

もし、「まつもとからの返事がないなあ」と思ったら もう一度尋ねてみてください。問題はそれへの対応が 届くかどうかよくわからないことだけど。

しかし、私からのメールが出て行かなくても、 (原稿提出以外は)あまり問題が起きないんだなあ。

自分の存在の小ささを感じる。

_ [Ruby] RubyKaigi 2007

で、いきなり遅刻してしまい、ささだくんの発表の途中で到着。

今年は多い。が、去年の倍以上という気はしない。 やはり階段状になっている会場の構造のせいか。

今年はプロジェクタスクリーンがふたつになっていて、 片方はIRCに開放されていた。 今、まさに発表している内容にpublicにツッコめるのは 大変楽しいが(ニコニコ動画みたい)、発表者としては 予想外のタイミングで笑いが起きたりして当惑したりして やりにくい。

まあ、発表者よりも参加者が楽しむべきなので あるべき姿なのかもしれない。

で、午後イチは私の発表、「2007年とその先のRuby」。 まあ、ちょっと苦心した揚げ句の発表である。

でも、あんまりウケなかったなあ。 で、その時のスライドと同じもの。

というのも、発表直後に操作ミスかEmacs 22のバグかなにかで スライドデータを失ってしまい、後のセッションを聞きながら もう一度記憶とログに頼ってゼロからスライドを描き直したからだ。

だから、発表したものとは微妙に違うはず。

で、飛行機の時間の関係でTimの発表の途中で抜け出した。 ささだくんからは、あいさつするかと言われたが、 そんな恥ずかしいことはできないのでパス。

でも、会場の人みんなが、まつもとが途中で抜けたことに気づいたろうな。 ごめんよ。Timの発表にもいろいろとツッコミたいことがあったのだが、 それは別の機会に譲ろう。

で、がんばって帰る。米子便にすればもうちょっと遅くまでいれたけど、 体力的にしんどいし。

_ [Ruby] RubyKaigi印象

今年のRubyKaigiは特異であった、と思う。

手作り感があふれるという点では、 同じようにオープンソースソフトウェアを扱っていても LinuxWorldなどとは全然違う。あっちはビジネスショーだけど、 こっちはそんなに商売っけはない。

とはいえ、昨年のRubyKaigiや他のOSCのような ユーザが楽しくわいわいやるという雰囲気とも違う。 それはスポンサーセッションが開かれたり、 ビジネスについても開かれているということが 原因になっているのかもしれないし、 あるいはちゃんと仕事になる(私のキーノート中に挙手してもらったところによると 1/3はRuby (on Rails)を仕事にしている)という状況が参加者の意識に影響があったのかもしれない。

しかし、最大の原因はやはり非常に意識の高いボランティアスタッフと 会場にあふれた「Rubyへの愛」だろう。 かつてこれほど「愛」が語られたソフトウェアカンファレンスが日本で 開催されたことがあるだろうか(いや、ない)。

これはきっと「愛の力(The Power of Love)」なのだろう。

_ [Ruby] 岩本隆史の日記帳 - Railsでは「ちゃんとしたWebアプリケーション」が簡単にできるんだろうか

Railsではちゃんとした「Webアプリケーションが簡単」にできるのか、 という疑問提示。

事実としては

• Railsによるアプリケーション作成は簡単
• 難しいこと(CRUDからの乖離など)をしなければ安全(のはず)
• Railsを使ったWebアプリは素のPHPを使ったWebアプリよりメンテしやすい

である。ただし、モデルの部分をがりがり書き換えるような複雑なWebアプリは やっぱりRailsでも危険性が残る。メンテしやすいのは利点だけど。

ほんとはここでtaint mode($SAFE=1)を使えば、 危険なデータは汚染されるから最低限のセキュリティチェックは 自動で行える(ので、PHPよりもずっとずっと安全)と書きたかったんだけど、 今調べたらRailsはtaint modeでは動かないんだって(だいぶ工夫しないと)。

これはRailsの不備といってもいいと思う。

せっかくのセキュリティ機能なんだし、デフォルトで活用してほしいなあ。

_ XML in 10 points

XMLの良いところ、10点。

ま、わからんでもないが、いずれも私に対してはそれほど訴求しない。

個人的にはRubyKaigiでTim Brayも指摘していた 「XMLはエンコーディングをいつも明示している」という点を挙げたい。 この点についてだけはXMLはYAMLやJSONよりもはるかに優れている。 いちおう「YAMLはかならずUTF-8」という規約があるようだが、 なかなか守れてないし。

_ [教会] 松江

先週のリアル・ホームアローンからもう1週間もたつのか、 とか、あの空の向こうではRubyKaigi 2007の二日目を開催中なのね、 とか思いながら教会へ。

今日の日曜学校のテーマは「偽善」。 ただ単に「良い行い」だけでは不十分で、 行いには「良い動機」が伴わなければならない、という話。

もちろん、「良い行いがない」のが一番良くないのだが。 より高いものが求められる、ということ。 ちょっと反省すべきものを感じた。

教会から帰ってから昼寝。 でも、寝過ぎるとかえってしんどいなあ、なんて思っていたのだが、 うっかり2時間以上寝てしまって、案の定つらかった。

生活リズムを維持するって難しい。

_ [Ruby] RubyKaigi 2007 記事

あちこちのニュースにそれなりに取り上げられてるみたい。 とりあえずITproから。

• 【日本Ruby会議2007】“爆発的拡大期”を迎えたRuby，テーマは「エンタープライズ」と「愛」：ITpro
• 【日本Ruby会議2007】まつもとゆきひろ氏が考える「Railsの次」：ITpro
• 【日本Ruby会議2007】JavaによるRuby実行環境「JRuby 1.0」正式リリース，作者Nutter氏とEnebo氏が発表：ITpro
• 【日本Ruby会議2007】「Rubyの生産性は他言語の1.6〜3倍」---楽天技術研究所 森正弥氏：ITpro

_ タッチパッド/トラックポイントに続くポインティングデバイス

トラックボールはなかったことにされているのだろうか(泣

うーん、パッドよりはマシに思えるんだけど、トラックポイントと比較した優位性は 「ボタンを押してクリック」だけかなあ。そこは別に困ってないんだけど。

_ [言語] Eiffel : An Advanced Introduction

Eiffel(私は「あいふぇる」と発音する)のチュートリアル。

私の知識は古いし(Eiffel the Language以前)、 この際、もう一度勉強し直すのもよいかもしれない。 問題はどうやって時間を取るかだな。

このぐうたらな私にも実践できる時間管理法を見つける必要があるのかもしれない。

いや、Webをぼーっと読んでる時間をなんとかできれば それだけで生産性は数倍になりそうな気がする。

はっ、こんなことを書いたら、 もしかして編集の人にネットを切られるかもしれない。

_ [Ruby] 六月水無月はぶにっき - Railsが普及した次の世界を想定すると・・・

はぶさんのところ。 冷静な視点が心地よい

んで、Ruby。というかRails。多分定着するんじゃないですかね。で、また酷いシステムが乱造されるのよ（ｗ　来年くらいにね日経コンピュータあたりで「Railsは基幹系に適用可能か？」みたいな記事が出てね、んで先行事例みたいなのが出てきて、再来年くらいに適用が進んでくる、と。そうすると 2010年くらいにはStruts的な位置づけになってくるんでしょうね。一方で多分アンチRailsというかオルタナなRuby製のフレームワークも色々と出て来るんだと思います。

_ [言語] 新言語 Xtalを作る日記 - Xtalの多値

Xtalの多値について。Xtalでは多値と配列では(効率以外は)同じ意味を持つように したのだそうだ。「じゃあ多値要らないじゃん」という印象も持つが、 純粋に最適化手法としてとらえれば良いのだろう、きっと。 シンプルで悪くないと思う。

ただ、多重代入で

a,b = [1,2,3]

が

a = 1
b = [2,3]

になるのは正直いかがなものかと思う。単純に切り落として

a = 1
b = 2

にした方が良いのではないかな。でないと、

a,b = [1,[2,3]]

と区別が付かないし。たぶん、切り落とすことで情報を失うことを嫌ったのだろう。 気持ちはわかる。

逆に「わかりにくい」と指摘されているRubyのブロックパラメータの

yield 1,2,3

と

yield [1,2,3]

の区別も、結局は情報を失うことを嫌ったものだから。 人のことは言えない。

1.9ではyieldと多重代入の仕様がちょっと変わっているのだから、 この機会にいっそ情報喪失を恐れずこの区別をなくしてしまうか。

_ [Ruby] 「企業システムとRuby with CTC」セミナー

朝から米子便で東京へ。 帰りが遅くなるので出雲便では間に合わないのだ。 ANAは久しぶり。

で、六本木のオリベホールへ。 Tim BrayやCharles Nutter、Thomas Eneboとお昼ご飯を食べながら雑談。

1時から開幕。

まあ、聞いたこともないような話ではないが、 なかなかおもしろいイベントであった。 Timがステージから落ちたり(低くてよかった)。

あとはイーシー・ワンやCTCで 実際にRuby on Railsを業務に使っている事例が紹介されたのは ビジネスユーザには参考になったのではないだろうか。 Railsだって万能ではなく、適材適所であるということが 明示されていたのも好感度が高い。

最後に私のプレゼン。 世の中の動きが速くなり、 ソフトウェアの重要度が高くなり、 ビジネスに直結するようになるにつれ、 ソフトウェア開発に「うまい・はやい・やすい」が求められるようになり、 それを解決するためもっとずっと生産性を高めることが必要になる。 その手段(のひとつ)がRuby(やRails)である、というような話。

ところで、ビジネスクリティカルという話で、 先日のANAトラブルについて触れたのだが(非難するわけではなく、 ソフトウェアのトラブルがビジネスに大きな影響を与える例として(明日は我が身だ))、 聴衆の中にANAの関係者がいて、担当者は青い顔をしたという話を耳にした。

うーん、言葉には気をつけないといけない。

_ [Ruby] エンタープライズ

某社の人たちと打ち合わせ。松江までご足労いただいた。

内容は明かせないが、その中で、

「エンタープライズ」って「規模のエンタープライズ」と「複雑さのエンタープライズ」がありますよね。

データ量・アクセス数などが増大する規模のエンタープライズについては ハードウェアの進歩もあってRubyやRailsでサポートできる領域が増えてきているが ロジックやデータ構造の複雑さに関しては、Railsも特に助けてくれない、という話。

具体的にRails(特にActiveRecord)では難しい事例つき。 そうか、こんなことしたいニーズもあるのか。 JavaなORマッパーはこういうのもサポートしてるのかな。

が、80:20則に従った割り切りがRailsの力の源でもあるので さまざまな状況が考えられる「複雑さ」を一概に支援するのも難しい話だ。

今、思ったのだが、「規模のエンタープライズ」と「複雑さのエンタープライズ」以外にも 「重要さのエンタープライズ」ってのもあるな。 大規模でも複雑でもないけど、止まったり誤動作したりすると大きな迷惑がかかるようなの。

_ [Ruby] [ThinkIT] オープンドリーム、RubyおよびRuby on Rails研修を開始

オープンドリームは以前アジア向け技術者研修で講師を出したところ。 あの時は基本的講習内容はうち(NaCl)で準備したのだが、 自前で講習を用意できるようになったらしい。

うちの約半額というのが素晴らしい。 うちも各種割引があるので実質の差はもうちょっと小さいだろうけど。

他にもうちのお客さんで講習を始めたところがあるんだが、 やっぱ、教育って魅力的に見えるのかな。

うちの実績だと(相当高額なのに)講習会単体では なんとか赤字にならない程度で推移しているくらいなのだが。 もっとも、講習会の売り上げ以外でのコネクションや成果もあり、 それはそれで馬鹿にならないのだが。

_ [Ruby] ドリコム、ウェブアプリコンテスト「Drecom Award on Rails」を今年も開催 - CNET Venture View

今年もやります、だそうだ。

昨年とはいくつか違いもあって、

• Railsオンリー(昨年はRails以外も対象)
• 合宿を開く

のだそうだ。今年も審査委員を引き受けた。 入賞者には私からの記念品が授与される(昨年は私のサイン入り「Hacking Guide」)。

_ [言語] John Lam on Software: Getting Started with the DLR: ToyScript

IronRubyの中の人、John Lamからのエントリ。 DLR (Dynamic Language Runtime) を使った動的言語実装例。

手元にDLRがないので試してないけど、 .NET+DLRならこんなに簡単、ということなら、 言語実装の楽しみを実感できる人(ホビー言語設計者)が増えるかも。

_ [Ruby] Ruby開発ストーリー

先日の日経BP技術賞受賞にともなう、 開発ストーリーが公開された。

ま、あまり目新しい情報はないけど、 とりあえず今の正直な気持ちも含めて改めてまとめておいた。

_ [Ruby] 思っているよりもずっとずっと人生は短い。: 6年後のStanding ovation

6年前、アメリカでfirst Ruby Conferenceで私が受けたStanding Ovationを 今年は日本でDave Thomasに返すことができてとても良かった、という話。

こういう話を聞くにつれ、Daveのキーノートは本当に感動的だったんだなあ、と思う。 ただ単に「面白い話」では、人の心は動かない。 彼が真摯に愛について語ったからに違いない。

_ So that's what 128 gigabytes of RAM looks like ... - The Something Awful Forums

128ギガバイトのメモリを積んだマシン。 えーと、なんか想像を絶する感じ。

_ [言語] Scott Rosenberg’s Wordyard >> Blog Archive >> Code Reads #10: Guy Steele, “Growing a Language”

Guy Steelの語る「成長する言語」について。

しかし、成長する言語って設計するのがすっごく難しいと思う。 既存の文法や機能が簡単に将来の可能性を狭めてしまうから。

原理的には(Common) Lispのような「なんでもあり」の言語が 一番「成長する言語」でありつづける可能性があるわけだが、 それはそれ、括弧が(別の意味で)障害になったりするわけで。

• 「普通の人」にも受け入れられる
• かつ、将来の成長の可能性を疎外しない

ような言語を設計するためには、

• 保守的な文法 (受け入れられるため)
• 高い抽象化機能 (高階関数とかオブジェクト指向とか)
• ライブラリで機能が提供できる枠組み

は必須だと思う。マクロは...悩ましいところだ。

_ [言語] 第11回　クロージャによる超軽量並行プロセスの簡単実装法：ITpro

クロージャがあれば並行プロセスの実現は簡単、という話。

とはいえ、1.8でのクロージャは重いから、Rubyだと「超軽量」とはいかないのが残念なところだ。

_ [Ruby] jijixi's diary - 『クロージャによる超軽量並行プロセス』を Ruby で

で、上記の「超軽量プロセス」をRubyで実装してみたjijixiさんによる例。

_ [言語] 404 Blog Not Found:perl - There's more than one way to duck-type

うーん、演算子によって型が決まるタイプの言語で 型変換用メソッドを用意するというのは よくあるテクニックであるとは思う。

Rubyでもto_*シリーズとしてこれらに相当するメソッドがある(例、to_str, to_int, to_io, etc.)。 しかし、それを「Duck Typingは演算子にやらせる」と呼ぶのは なんか違うような気がするなあ。

_ B000J109EM

B000J109EM

先週購入した。前のプリンタが印刷できなくなったので。

で、

• 印刷が速い
• しかもきれい
• 画面で直接確認できるのでSDカードからの印刷が簡単
• Linuxからも印刷できる

と不満点はなし。あ、あえて難点を言えば、ちょっとインクが高いかな。 まあ、前は4色、今回は6色だから仕方がないと思うけど。

最初、用紙設定がL版になっててLinuxからの印刷が断ち切れてたけど、 pipsliteコマンドでちゃんと用紙サイズを設定したらちゃんと印刷された。

_ 傍聴

ひょんなことから裁判の傍聴をすることになる。 私の知らない世界を見た気がした。

ドラマとかとはまた違う。

_ [言語] Katahdin

Katahdinは言語の文法や意味が実行時に変更可能な言語。 文法や意味が揺らがないことを目指したRubyとはある意味対極の言語である。

作者がイギリス陸軍に入隊するため開発が継続できないという事情も珍しい。 「パブリックドメインだから好きにして」とのこと。 Mono上で動作する。

_ Trickles protocol

ちょっと読解に自信がないのだが、 プロトコルに継続を含めることにより状態のないサーバで トランザクション/セッションを実現するプロトコル。

が、リクエスト/レスポンスに継続を含めると 継続の書き換えが問題にならないかな。 適当に暗号化すれば問題は回避できるかな。

_ Google-perftoolsを使ってCPUプロファイリングをとる - PS3 Linux Information Site

Google-perftoolsなんてのがあるって知らなかった。

プログラムを書き換えることで一部分だけプロファイリングできるのは 便利かもしれない。

_ [教会] ワード活動

下二人の子を連れて、宍道森林公園でワード活動。 メインの活動はカマドでカレーを作るというもの。

ご飯は電気炊飯器で炊くという点が不徹底ではあるが(これだから文明人は)、 火加減が難しいカマドでの調理にもかかわらず十分においしい。 カレーというのは人類の偉大な発明だと思う。

インド人は素晴らしい。

その他、縄とびしたり、フリスビーを投げたり、いろいろ遊ぶ。 凧揚げが面白かった。うちでも凧、買おうかなあ。

少々くたびれた。

_ [言語] David A. Wheeler's Blog - Readable s-expressions and sweet-expressions: Getting the infix fix and fewer parentheses in Lisp-like languages

Sweet Expressionは

• インデントベースのブロック化
• 関数呼出し記法
• 中置記法演算子

の導入により、「普通の外見」を持つように定義されたS式。

そこまでする必要があるのか、というと疑問なのだが、 冷静に考えると、あまり宣言してないだけでRubyのやってることもたいして変わらないような 気もしないでもない。結局は通常言語の文法で(ほぼ)Lispのセマンティクスを提供しているし。

_ [言語] fifty_questions_for_a_prospective_language_designer [the libarynth]

未来の言語設計者へ50の質問。

50は多いのでここに書き写しはしないが、 新しい言語をデザインする時に自問してみる価値のある質問が多く含まれているように思う。 ま、主たる目的はどうしたって「楽しいから」になるに決まってるんだけど、 それ以外に、その言語が対象としたい領域や機能などが明確化される、かもしれない。

_ [Ruby] Raw Block: Ruby vs JRuby Fractal Benchmark

Ruby (1.8)とJRubyでマンデルブロ集合を計算するベンチマークを行ったところ、

• Ruby: 6.732136
• JRuby: 68.757000

と大差がついた、という話。

ただし、この話には続きがあって、 Charles Nutterからのコメントによれば(彼ってまめにあちこちコメントするよね)、 このベンチマークでは主要な関数が１度しか呼ばれないためHotSpot最適化が効かず、 このような差がついたとのこと。

jruby -J-server -J-Djruby.jit.threshold=0 -O fractal.rb

と起動すれば、JRubyも6.454000と、1.8とほぼ同等(ほんのちょっと高い)性能を示す。

それぞれのオプションの意味は以下の通り。

-J-server

Server VMを使う

-J-Djruby.jit.threshold=0

すべてのメソッドをJIT対象にする

-O

ObjectSpaceを使わない

_ [言語] Seven Deadly Sins of Introductory Programming Language Design

昨日、プリンタのテストとして印刷したPDF。 最初に印刷するのがこんなタイトルだっていうところで、 すでに病膏肓に入るって感じ。

いわく「初心者向け言語設計における7つの大罪」。

ついやってしまう初心者向け言語設計における「やってはいけないこと」、 それから逆に「やった方がよいこと」。実に参考になる。 この論文は後で時間をとってもう一度考察したい。

しかし、今気がついたけど、この論文書いたのって Damian Conwayじゃん。Perlの。 どういう風の吹き回しなんだろうか。

追記

リンクが切れてるそうで、すみません。 では、こちらを参照のこと。

_ [教会] 父の日

今日は父の日である。 朝、末娘が「おとーさん、おめでとー」と言って包みを持ってくる。 開けたらムーミン柄のネクタイであった。なぜムーミン？

ありがたい。妻にもお礼を言ったら「なんのこと？」ととぼけていた。

聖餐会のテーマも父の日。こちらは単に「父親に感謝する」というだけでなく、 天父、つまり神様の方が主要なテーマ。 私も話す割り当てがあった。

集会終了後、教会の用事で米子へ。

で、(ついでに)父親に会い、ちょっとした贈り物を。

_ [Ruby] Lazibi: Python-style indenting for Ruby

一部で根強い人気を持つPythonスタイルのインデントブロックを Rubyで実現するプリプロセッサ。

なにもそこまで、と思わんでもないが。

インデントブロックはそれ自身は致命的に悪いアイディアというほどではない。 タブとスペースの混在は面倒だけど、明確にタブを禁止するとか、手はいくらでもある。

だけど、 Pythonみたいに「それしかない」と式と文の明確な分離を招く(ブロックを含む式が書けない) ので、あまり賛成しない。Haskellみたいにデフォルトではインデントで、 必要に応じてブレースを使うというのがある意味理想的なんだろうけど、 同じことを記述するのに二種類ある冗長さは、Pythonな人たちは受け入れがたいのかもしれない。

あと、コメント欄とか掲示板とかでインデントが消えちゃうことが たまにあって、インデントブロックな言語だと情報が完全に失われちゃうのも痛い。 ブレースやendを使う言語ではインデントは冗長なので 復元可能なのに。

_ レジデント初期研修用資料: 社会の豊かさと不実の谷

貧しさと豊かさの間に「不実の谷」があるという話。

小さなコミュニティだとひとりひとりがわかるから、 貧しくて貢献できないことはあっても「不実」は発生しない。 コミュニティが十分に豊かだと、けちけちする必要がないからやはり「不実」は発生しない。

しかし、コミュニティが半端に大きく、 かつ半端に豊かだと、「ひとりくらい水を混ぜてもバレないだろう」という 不実が自己組織化される。

うーむ。

人間の弱さと愚かさと考えるべきだろうか。 あるいは、これを克服することこそチャレンジだと考えるか。

コミュニティの機能不全については 「ネットコミュニティが崩壊するとき - GIGAZINE」も興味深い。

_ [Ruby] If Ruby is so great << Metacircular thoughts

みんな「Rubyはすごい」って言うけどさ、 そんなにすごいってんならどうして

• キーワード引数の代わりにハッシュを使わなきゃならないの？
• そんなこともできないのに「Acceptable Lisp」ってのはどういうこと？
• RubyにはまともなVMがないの？
• パフォーマンスが必要な時Cコードを書かなきゃいけないの？
• IDEといえばJava/C/C++のものの真似ばかりで、SqueakやVisualWorksの真似をしないの？
• どうしてRubyはSmalltalkが実現してきたものを無視するの？

というような話。

どっちかっていうと文句は歓迎する。特にちゃんと根拠があるものについては。

VMとパフォーマンスについてはYARV(1.9)に期待してもらおう。 すくなくともマイクロベンチマークでは劇的に速度が向上する。

キーワード引数は残念ながら1.9にも入らない(予定)。 もうちょっと待ってもらう必要がありそうだ。

IDEについてはよくわからない。 使いこなしていないせいだと思うのだが、 個人的には、JavaのものだろうとSmalltalkのものだろうと、とにかくIDEなるものが 使いやすいと思ったことがないからだ。自分が使いやすいと思ってないものは 作れないようね。

後、Smalltalkを無視しているように感じているのは、 ワークスペースモデルを放棄しているからではないだろうか あれもちっとも良いとは思えないんだよねえ。

さて、この「If Ruby is so great」については、 反論(？)エントリも登場している。

ま、要するに「Ruby is great」と言っても、 欠点がないとか万能であるとか主張している人は誰も居ないんだから、 批判は無意味だとかいうようなこと。

それはそれとして、一番おかしかったのはここ。

With the expansion of the Ruby and Ruby on Rails communities, I’d love to see a trend towards the adoption of a compromise between the excellent marketing of DHH, and the humble and objective nature of Matz (it’d be dangerous if you got it the other way around ;-) ).

RubyとRuby on Railsコミュニティの発展に従って、 DHHのすばらしいマーケティングと、 Matzの謙遜さの間の妥協が受け入れられるのをみたいと願っている。 (DHHの謙遜さとMatzのマーケティングだと危険なことになる (笑))

_ [Ruby] ChadFowler.com InfoEther

4274066592 『4274066592』の著者でもあり、 RubyConfやRailsConfの立役者でもあるChad Fowlerが、 これまたRubyConfで大きな役割を果たしている Rich Kilmerの会社「InfoEther」のCTOに就任したという話。

InfoEtherはバージニア州にあるのだが、 Chadは今まで通りデンバーに住んだままでCTOの仕事をするのだそうだ。 Richのパワフルな「現実歪曲空間」プレゼンテーションと Chadの人柄の組み合わせは新しいものを産み出すかもしれない。

実はこの件については、しばらく前にRichが 私に間違えてSkypeかけてきた時に 聞いていたのだが、正式に発表になるまでは黙ってようと思ったのだった。

_ [言語] Alexandre Vassalotti >> Pickle: An interesting stack language

ミニマリスト向けスタック型言語 on Python。 面白いなあ。実用的ではなさそうだけど。

追記

kenさんからの指摘にあるように、PickleってのはPythonのデータシリアライズライブラリのこと。 PickleのフォーマットがASCII表現で一種のスタック型VMを使った「データ表現言語」に なっていることがネタなのに、私が読めてなかった、ということ。

恥ずかしい。

_ [言語] Is TIOBE Fatally Flawed? << Sententia cdsmithus

言語の人気ランキングといえばTIOBEランキングだけど、 それって本当に正確なの、という疑問。 まあ、Googleのヒット数をベースにしているという時点で 正確も何もないわけだが。

そして、独自に計算したランキングも載せているのだけど、 どう考えてもTIOBE Indexの方が現在の現実を反映しているようにみえる。 ということは、なにか特別な補正をかけている？

_ [言語] Whirl - Dizzy Programming

Whirlは以下の最新機能を達成すべく設計された。

• 継承
• 単純さ
• 使いやすさ
• XML
• 保守性
• ポリモーフィズム
• 柔軟性
• パワー
• 引き算
• グリルチキン

しかし、不幸にしていずれも達成することができなかった、という言語。

言語機能としての「グリルチキン」とはなにか、というツッコミは とりあえず置いとくとして、引き算すらないというのはどういうことか。 ちなみに命令は0と1しかない。

詳細はWebページを見ていただくとして、 1+1を計算して出力するプログラムは以下のようになる。

011000001111000011111000001111000011111000001111000
011111000001100100000110011111000111000111100011001
11000000000111110001000111110011001111100010001100

勘弁して。

_ 九州へ

宮崎で開かれる人工知能学会に参加するために、まず福岡へ。 ここで宿泊。

福岡空港と博多駅の近さに感動する。 ってか、市の中心街まで地下鉄で５分ってどういうこと。 なんか都市設計がまずくて空港から遠いところばっかり見てるから 感動的である。

福岡って面白い街。九州全般に(飛行機を使えば)交通の便は悪くなさそうだし、 意外と住みやすいかも。

_ [言語] 新言語 Xtalを作る日記 - Xtalの多値3

私のエントリに対するお返事をいただいた。

簡単にまとめると

a, b = 1,2,3

で、切り落とさず

b = [2, 3]

になるのは

a = 1,2,3

で

a = [1,2,3]

となることとの整合性を取るためなのだそうだ。それが良いかどうかについて、 私の意見とは異なるものの、非常に真剣に考えた結果であることが 伝わった。好感が持てる。

また、

a,b = [1,2,3]

と

a,b = [1,[2,3]]

の区別が付かない点については、「代入においてそれらはそもそも同一視される」のだそうだ。 これは正直言って想像の範囲外であった。

Perlのリストのように勝手に展開されちゃってネストできないのは かなり使い勝手が悪かったので、それはどうなんだろうな、と思わないでもないのだが、 「ネストできない」と「末尾のネストは展開されたのと同じ」と見なすのでは ちょっと違うのだろうな、きっと。

配列でなくLispのリストのようなデータ構造であれば、

(1 2 3 4)

と

(1 . (2 3 4))

はそもそも同じであって、 連鎖と同一視されるのは逆に自然なわけだから、 実装的にも配列であるということを重視しなければ それほど悪くないのかもしれない。

_ [Ruby] 人工知能学会招待講演『Rubyのチカラ』

福岡から朝一番の便で宮崎へ。 宮崎空港からシーガイアへ。

昼食後、招待講演。タイトルは昨年末に福岡で講演したものと同じだが、 中身は2/3は新しくなっている(でも、同じ誤字が残ってた)。 また、スライドの1/3は今回のための新作。

さて、人工知能ってことで緊張したが、 あまりアカデミックでないRubyの話が学会の出席者(主に学生)に どのように通じたのだろうか。

後で話す限り先生方にはおおむね好評であったようだが。

_ [言語] Python 3000 Status Update (Long!)

Python 3000 (コードネーム、リリースされる時にはPython 3.0)は 今年前半の終わり頃(ってことは６月末？)に最初のアルファリリース。 正式リリースはその１年後を予定、という話。

Python 3000ネタはずっと引っ張ってきているので あまり目新しいことはないのだが、現実路線のPythonらしいといえば Pythonらしい。

Python 3000が始まった頃の「なにかすごいことが起きそう」という 興奮はもうないよね。まあ、アルファリリース直前まで興奮と混乱に あふれていても困るばかりだろうけど。

これが済んだら、今度はPython 4000を始めるんだろうか？

_ [Ruby] Ask Reddit: Why can't Ruby people just admit Ruby is slow? (reddit.com)

「なぜRubyな人たちはRubyが遅いことを認めようとしないのか」という話。

えー、そんなことないと思うけどなあ。

ただ、100万回ループとか竹内関数みたいなマイクロベンチマークの成績だけで遅いといわれても、 実際の仕事を十分に速けりゃいいや、という話はよくする。 で、おおかたの場合にはRubyも十分速いんだよね。

言語処理系の速度ってのは使い方に大きく左右されるので、 たとえば、私はPHPについて、「とても速い」という人と 「とても遅い」という人の両方に会ったことがある。

どちらが間違っているというわけではないだろうが、 ある人がある言語のことを遅いと言っていても、 それが自分にあてはまるかどうかはわからないということだけは言えるだろう。

_ [Ruby] ongoing・Tim Brayによる日本レポート

目新しい点としては

• 私のTシャツについての言及。JRuby Tシャツはあちこちで人気であった。 また前夜祭でのPython Cookbook Tシャツの件に言及したのもTimだけだった
• m17n。Timに即席のデモスクリプトを実行してみせて、 ちゃんと文字単位で実行しているのを見せた。 気に入ってもらえたようでうれしい。 combined characterについて質問してみたのだが、 文字列処理の前に正規化されているはずだし、 combined characterを１文字として処理するのはinsaneなので コードポイントを文字とみなして構わない、という意見をいただいた。 UnicodeについてはTimが私より私がTimより正しいということはないだろうから、 素直に従うことにする(その方が楽だし)。

かな。

_ 宿泊

夕方の飛行機で福岡に戻って二泊目。

電気屋好きはヨドバシカメラを散策して大満足。 夕食は4Fの天ぷら屋。おいしかった。

客がぜんぜん居なくて不安だったけど。

_ 帰宅

早朝、ホテルから空港。 空港から0745の出雲便で自宅へ。

しかし、あしかけ３日の出張と言うのはしんどいな。

_ [言語] Lisp500

Cで500行でLispを書いた、という話。

昔あったSIOD (Scheme in One Defun)より小さいなこれは。 言語処理系に興味がある人は、こういう小さい処理系を読むことから 始めるといいと思う(ただし、lisp500.cは読む前にindentにかけるべき)。

私もRubyを作る前に

• gawk
• scm
• siod
• stk
• emacs
• caml

などのソースを読んだものだった。 今見るとあちこち影響が残ってるような気がする。 関数や定数の名前のつけ方とか。

最近は逆にRubyっぽいソースコードとかを見かけることがある。

因果応報？ いや違うな、輪廻転生？

_ [言語] about:cmlenz - Announcing Babel

Python向けI18N/L10Nフレームワーク。 localeデータベース、メッセージカタログ機能など。

すばらしい。Rubyもいつまでも負けていられないなあ。

_ [OSS] ユメのチカラ: Community Based Development

Miracleのよしおかさんによる「コミュニティのチカラ」の話。

Rubyや私の話も出てきて気恥ずかしいのだが、 「新しいやり方」をスーツ族に伝える熱意は伝わる。 そして、スーツたちもそろそろ気がつきはじめている。

我々の期待よりはだいぶ遅かったけれども。

_ [言語] 第5回 CodeGearデベロッパーキャンプ $(G!9 資料ダウンロード

先日のデベロッパーキャンプの資料が公開されている。 こういうビジネスセミナーの資料は非公開のことが多いのに ありがたい。

また、ビデオも公開されている。

_ 上京

楽天技術研究所フェローとしての初仕事としての ミーティング出席のために上京。 なんか毎日飛行機に乗ってるな。

• 火曜 福岡へ
• 水曜 福岡<=>宮崎
• 木曜 松江へ
• 金曜 東京へ
• 土曜 松江へ

マイルは溜まるが、疲れる。

_ [Ruby] ミニ合宿

で、せっかくの機会なのでささだくんのところに寄って打ち合わせ。 そしたら、akrさんもいて、たくさん有益な意見をいただいた。 おかげでブロックパラメータなどいくつか放置されていたところの 細かいところが決まった(と思う)。

_ 楽天技術研究所ミーティング

研究所スタッフとの挨拶から始まって かなり突っ込んだ研究テーマまで。 現時点ではまだ妄想レベルだが、 リソース(時間・人・お金)を突っ込めば実現性は高いと思う。

内容は(現時点では)公開できないが、 成果はオープンソースにするという言質は取りつけた。

_ 世界が認める頭脳が集結したガレージ--検索エンジンのPFI - CNET Venture View

PFIの人たちが「頭良さそう」なのは認めるけど、 それを示すのに「彼らは皆、東大・京大、および同大大学院の現役学生、もしくは卒業生」 という表現のを使うこの記事は「頭悪そう」。

_ Stevey's Home Page - Effective Emacs

Emacsテクニック。

さすがにEmacs歴20年近いと、知らないテクニックはほとんどなかった。 とはいえ、じゃあ、なんでも知ってるかと言うとそうはいかないのが Emacsの恐ろしいところだが。

最近だと

• mwheel
• mouse-avoidance-mode

を「発見」した。

_ [教会] 神殿

広尾の神殿に参る。

六本木の方から向かって広尾の裏通りを抜ける。 この辺の道を通るのは２０年ぶりのような気がする。 寝坊したのでセッションはひとつしか受けなかった。

浜松の人に出会う。 その他にも知人の息子さんや、弟さんらしい人を見かけたのだが、 声をかけるチャンスがなくて確認できなかった。

２時の飛行機で松江に帰る。

_ [Ruby] まつもとゆきひろ×結城浩，Rubyを語る：ITpro

先日の結城浩さんとの対談がWebで公開された。 同じものが今月発売の日経ソフトウェアにも掲載される。 同じタイミングで公開すると言うのは大胆なことではある。 ま、それだけ特集全体に自信があるということなのだと思う。

結構好きかってなことを話している。 ま、面白がって読んでいただければ幸いである。

_ [OSS] Size isn't everything for the modest creator of SQLite | Technology | Guardian Unlimited Technology

SQLiteの開発者、Richard Hippのインタビュー。

数ある「オープンソース」ソフトウェアの中でもSQLiteはちょっと特異で、 完全にパブリックドメインを維持している。 また、SQLの解析のために独自のコンパイラ・コンパイラ(lemon)を実装してたりする。

ある意味すごく徹底してかっこいい。

また、会社を経営しているうえに、 SQLiteのためにアシスタント(Dan Kennedy)を雇っているというのも 尊敬する。

_ [OSS] ITmedia エンタープライズ：OSJ、PCIホールディングスの100％子会社に

うちの取引先でもあるオープンソースジャパンがPCIホールディングスの子会社になった、という話。

なんの事情も聞いていないので、背景やらなんやらはさっぱりわからないのだが、 少なくとも当面事業方針に変更はないようだ。 このことから「オープンソースでビジネスするのは難しい」という結論が 引き出されるというわけではない、と思う。

_ [Ruby] 思っているよりもずっとずっと人生は短い。- 小飼弾氏の『Rubyクックブック』評に反応する

4873113245 弾さんは「失格。」と断じたRuby Cookbookではあるが、 単独の書籍としては欠点があっても、 まわり(既存書籍)の状況や、費用対効果を考慮すると、 妥当だったかもしれない、という意見。

実はまだ私自身はRuby Cookbookを読んでいない(入手していない)ので、 どちらかに味方するつもりはないのだが、 複数の書籍に名前が乗る身としては、 書籍を企画する・執筆する・翻訳する・執筆する・出版する ことはたくさんの要素がからみあう大変難しい課題であって、 だれもが満足するものができることは滅多にないことについては よーく知っている。

_ [教会] ジョセフ・スミス２００年目のクリスマス　ソルトレーク・世界最大の大合唱

通常の集会。 今週は私が日曜学校で教師する順番。

集会終了後、有志で『ジョセフ・スミス２００年目のクリスマス　ソルトレーク・世界最大の大合唱』を観た。 NHK作成ということで、一応第三者的な態度で構成されていた。

大変よろしかったが、出張疲れで途中うとうとしていたところがあった。 あとで改めて見直そう。実は購入しているのに見ていなかったのだ。 最近、こういうのが多いな。去年、ユタで買ってきたDVDにも見てないのがあるし。

_ [Ruby] ミニ合宿ふたたび

東京出張。多いぞ。

秋葉原ダイビルの東大オフィスで ささだくんと会う。 ま、懸念材料はおおかた金曜日に片づいた(本当に？)なので、 さほど難しい話はしなかったが。

途中でB4の学生さんが来て、彼の課題である RHC (Ruby High-performance Computing)HPR (High-Performance Ruby) について 現状を聞かせてもらった。

大変興味深いうえに、楽天技術研究所の研究テーマとややかぶっていたので 面白く聞かせてもらった。まだはじまったばかりだけど。 これは産学共同を考えるしかないか。

_ [Ruby] まつもとゆきひろ×結城浩，Rubyを語る - enbug diary (2007-06-24)

結城さんとの対談についてのおくじさんの感想。

「変えないほうが楽」だなんて、 まともなソフトウェア開発をやっている人間なら、決して言葉は吐かないはず

いや、まあ、多くのフリーソフトウェア開発者ならそうであるという点においては 同意しますが(だからこそ、「Rubyは変わり続けている」わけで)、 しかし、「まともなソフトウェア開発」とくくってしまうのは ちょっと広すぎるかもしれない。

「フリーでないソフトウェア開発はまともでない」という主張でない限り。

結城さんは執筆者でソフトウェア開発は本業ではない、というのもあるかもしれないけど、 「変えない方が楽」と考える職業的ソフトウェア開発者もたくさんいる。 当然だがこの「変えない」の対象は「外面からわかる点」である。 外側は変えないでリファクタリングや性能向上だけ考えていた方が楽という意味だ。

もう一つ、

分散化が必須という状況では、言語なり処理系なりが透過的な機能を提供して、それで本当に嬉しいの？と思うのです。

そりゃあ、中にはいわゆるバカチョンパラレルで十分なケースもあるわけで、そういう時には嬉しいのかもしれません。

おっしゃることはよくわかる。しかし、私は今後「いわゆるバカチョンパラレルで十分なケース」が増えると考えていて、それを支援したいと考えているので、HPCをRubyで、というわけではない。 Rubyが本質的に遅いことはわかっりきっていても、それでも「もっと速く」という人は絶えないわけで。 本気で「並列で性能！計算速度命！」とかいう話なら、そりゃ明示的な指示は必須だろうし、 そもそもRubyみたいな言語を使う気にならないだろうけど。

最近だとFortressがそういうHPC分野で透過的な言語を目指して、あまりうまくいっていないようですね。

_ [楽天] データセンター見学

某所にある楽天データセンター(の一つ)を見学させていただく。 データセンターってどこも住所を明らかにしないのね。 テロ対策？

規模やらなんやらに感動する。 滅多に見れない大きなコンピュータや、サーバのつまったラックの数もそうだけど(60テラのディスクとかはじめて見た)、 一番感動したのは、将来にわたって拡張しやすいように、考慮され、企画され、整然と構成された データセンターの「仕組み」である。 過去、いろいろ「痛い目」にあって学んだことが活かされているのだそうだ。 過去のデータセンターでは、ネットワークケーブルが地層になったり、 電源ケーブルとネットワークケーブルが絡んだり、 マシンが重すぎて床が沈みそうになったり、 大変なこともあったのだそうだ。

一緒に見学に参加した、うち(NaCl)の社長は、 「楽天はデータセンター設計部門を子会社化して事業化すべきだ」と 強く主張していた。本当にそうかもしれない。

_ [言語] 複数のプログラミング言語を学ぶ意義：ITpro

おお、面白そうな記事が出たのぉ、と思って読み始めたら 自分の書いた文章だった。最近、オープンソースマガジンや 日経ソフトウェアに書いた記事がWebに転載されることが多くて(それは契約の範囲内なので何の問題もないのだけど)、

面白そう→結局自分の記事だった

ということが頻発している。うれしくない。

_ [言語] The Language Guide

各種言語の簡単なまとめとリンク。

HTMLとかXMLのようなプログラミング言語でないものが含まれていたり(AcronymにLanguageを含んではいるけど)、 Euphoriaのようなあまり知られていないものが含まれていたりするのが面白い。

一方、Rubyはまだ名前さえ含まれていない。

あ、そうそう。Euphoriaは最近オープンソース化されたそうだ。 いわゆる「今風の言語」ではないけれど、要チェック。

_ [言語] OCaml Language Sucks

1年ほど仕事でOCamlを使って感じたOCaml言語のダメなところ、という話。

私自身はOCamlを使っていないし、まだ『4839923116』も完読していないので、この批判が正当なものかどうか判断はできないけれど、 今まで言語批判を読んできた経験から推測すると、 大半は設計思想との見解の相違で、 ごく一部正当なものがあるというところだろうか。

もっとも、このような批判が出ることそのものは非常に健全で、 このような批判を改めて検討することで、 自分の設計思想が本当に正しいのか再確認するチャンスを得ることになるし(時間を使ってしまうけど)、 また、今まで思いつかなかった発想の源になる可能性もある。

というわけで、Rubyに対する批判も甘んじて読もうと思っているのだ。 時々、心が痛むけれども。

_ [言語] jessenoller.com - Python 3000 Resources

Python 3000に対するBlog界の反応。

なんとなくforkを懸念する否定的な意見が目立つような気がする。 ま、実際、現行PythonとPython 3000との間で(当初の予想よりはるかに小さいものの)、 非互換性があるのは確かで、結果的に、いつまでもPython 2.xにとどまる人と、 積極的にPython 3.xに移行する人の分断が、ある程度発生することは避けられないと思う。

が、それはしょうがないんじゃないかなあ。 誰かも書いてたけど、Perl5とPerl6よりは小さいわけだし。 たぶん、Ruby1.8とRuby1.9の間よりも小さい。

その辺を気にするのがPython的コミュニティってこと？

いや、邪推が過ぎるか。

こっちにもPython 3000リンク集を発見。

_ [Ruby] Where I Come From

かつてSmalltalkerであったRick DeNataleがRubyに対して思うところ。

いろいろ面白いことがあって、言語に興味があって英語にさほど抵抗がない人には ぜひ読んでいただきたいのだが、個人的に一番面白かったのは以下の引用部分。

I always thought that Smalltalk would beat Java, I just didn't know that it would be called "Ruby" when it did.

私はいつかSmalltalkがJavaを打ち倒す日が来ると信じてきたが、 そうなった時には、それがRubyという名前で呼ばれるとは思いもしなかった。

−Kent Beck

ま、実際問題、Rubyはいろんな意味でSmalltalkではないのだが、 それなりに(頭の柔らかいSmalltalkerに嫌われない程度には)、 Smalltalkの精神を受け継いでいる、らしい。

_ [Ruby] InfoQ: Coming From Ruby

David Alan Blackによるエッセイ。

新たにRubyを学ぶ人は今まで慣れ親しんだ言語との違いが気になって、 「ここがおかしい」、「あそこを直したい」と感じるみたいだけど、 ちょっと待って。Rubyにはそれなりに歴史と理由があるんだから、 しばらくとどまって、「Ruby流」に慣れてからそのことを考えようよ。 決して後悔しないから。

というような話。

ま、実際「Rubyを変えたい」という話の大半は 「私の知ってる言語XXXとここが違う(から直したい)」というものであるので、 そうしていただけると、私は助かる。

が、そういうリクエストの中にも有意義なものがあったりするから油断がならない。

_ [Ruby] Good News

パフォーマンス(の多く)は処理系の性能よりもアプリケーションアーキテクチャで決まる、という話。 割と当たり前。

The performance boosts associated with a “faster” language would give us a 10-20% improvement, but thanks to architectural changes that Ruby and Rails happily accommodated, Twitter is 10000% faster than it was in January

より「高速な」言語を使うことで性能は10-20%程度向上するだろう。 しかし、RubyとRailsで容易に実現できるアーキテクチャ変更のおかげで Twitterは１月と比較して10000%高速になっている

10000%って100倍だよね。

_ Wikipediaロゴの誤字

この画像をよーく見てほしい。 これはジグソーパズルの各ピースに各国語の「Wikipedia」に相当する表記の 先頭の文字を配置したもののはずである。

われらが日本語は上の方の割と目立つ位置になっている...あれれ？

「ウィキペディア」なのに「クィ」になっている

上記リンクによるとサンスクリット語にも間違いがあるのだそうだ。 まあ、「間違いは人間の常」だが、Wiki本文と違ってロゴ画像は訂正しにくいよなあ。

_ [Ruby] 日本 Ruby 会議 2007 - Dave Thomas Keynote

RubyKaigiで絶賛だったDave Thomasのキーノートのログ。 オリジナル英語版もある。

ま、愛など精神性について語るのはRubyイベントのキーノートではわりと伝統なので、 これがことさらにウケたということは、

• Dave Thomasのプレゼンマジック
• RubyKaigi出席者の受容性/感受性

の双方がちょうどよいバランスだったということだったんだろう。 これに出席した人は日本のIT系イベントのひとつのエポックを目撃した、のかもしれない。

_ [言語] 川合史朗＠Gaucheは、ハワイで俳優をしている／Ｔｅｃｈ総研

いやあ、川合さんって人は私にないものをいっぱい持ってるなあ。

一応、私も高校時代演劇部のお手伝いしたこともあるし、 アスキーのアノ本も読破してたりして、 ニアミスしてたんだけどなあ。 やっぱ、素材の違いかなあ。

いやいや、他人を妬んでも仕方がない。

_ [言語] Gforth and gcc ”progress” - comp.lang.forth | Google Groups

言語実装者のあこがれ、gforthの「中の人」こと、 Anton Ertlによる、「GCCは堕落しました」という話。

gforthはgcc 2.95で最速で、 gcc 3.x、gcc 4.xとバージョンが進むにつれて、

• あるべき機能がまともに動かなくなる
• バグがいつまでも直らない

などの理由でどんどん遅くなっているとのこと。

gforth(っていうかvmgen)のような「なにやってるかよくわかんないくらい高速」な プログラムだとコンパイラのバグとか踏みやすいんだろうねえ。

_ [OSS] ITmedia エンタープライズ：第4回　Emacs対vi

また自分の記事だ。

なに書いてるかすっかり忘れてて、「この記事、面白いっ」とか思ってしまったことは 秘密だ(自画自賛？)。

_ [言語] Steve Yegge、RailsをJavaScriptに移植する

Googleにおける開発者の生産性を引き上げるため、Steveは会社にRails(したがってRuby)を言語として採用するように訴えたが、それが叶わないとなると(Googleはインフラでサポートしなければならない言語の数を増やすのをとても嫌っている)、彼は欲求不満のプログラマがみんなするだろうことをした。RailsをJavaScriptに移植したのだ。1行1行、6ヶ月で、2000時間かけて。

えーと、とてもクレージーだ(良い意味で)。

実際のところ、この半年の作業を終えた彼の感想がとても聞きたいものだ。

• JavaScriptサイコー！
• Rubyサイコー！

のいずれかではないかと想像するのだが。

つまり、Rails相当を記述できるくらい JavaScriptはすばらしい可能性に満ちあふれた言語であることを実践によって 確認して喜びに満たされているか、あるいは、 行きがかり上最後までやり遂げたけど、Rubyなら簡単に書けることがJavaScriptでは繁雑なので、 すっかりJavaScriptに幻滅してしまったか。

どっちだろう？ あるいはそれ以外？

いずれにしても、私にとって厳然たる事実は、 私がGoogleに行かない理由がまたひとつ増えた、ということだ。 先方も私を欲しがってないと思うけど。

_ [言語] [ThinkIT] 第3回：PHPの、その先にあるもの (1/3)

しかし、現実には上手くいきませんでした。その後Javaの登場でオブジェクト指向が一気に加速したようにみえましたが、筆者としては大きな成果は生み出されなかったように感じています。

そこに登場したのがPHPです。

これまで叫ばれ続けてきたにも関わらず、なかなか実現できなかった「部品化」の切り札が、JavaではなくPHPなのだ、というのが筆者の最近の期待です。上で述べた「アプリケーション」とは異なる方向かもしれませんが、オブジェクト指向についての長年の夢をPHPが解決してくれるように感じています。

「Javaで成果を生み出さなかったオブジェクト指向(部品化)」が (他の言語でなく)PHPでならより良く達成できるとはどうにも思えないんだが、 なにかここに書かれていない「根拠」があるんだろうか。

まあ、人がどう感じるのも自由だし、 人の「感じ方」はいろいろなものを客観的に比べて「感じる」わけではないのだから、 Javaで感じなかった「達成感」をPHPで感じられたら、 他の言語はどうでもいいというのもひとつの態度であると理解はできるけどね。

PHPが切り札になるんだったら、RubyでもPythonでもLispでもいい、 「もっとマトモな言語」だったらより強い切り札になると思うなあ。

_ 松江へ

ホテルでのんびりしてたら「午後、松江で打ち合わせがあるから帰れるか？」との電話。

はいはい、帰りますよ。 JAL第2便には間に合うだろう。 もうちょっとゆっくりするつもりだったんだけど。

_ [Ruby] On The Horizon : Ten Things I like about Ruby 1.9 - O'Reilly Ruby

Gregory BrownがRuby 1.9の新機能で好きなこと１０選。

1. Enumerator is in core and more tightly integrated

   a = 4.times
   a = a.each
   a.inject{|s,x| s+x}         # => 6

2. Enumerator#with_index

   [1,2,3,4,5,6].map.with_index {|x,i|[2,5].include?(i) ? x : x*2}	#=> [2, 4, 3, 8, 10, 6]

3. Better Array#to_s and Hash#to_s

   [1,2,3,4].to_s  # => "[1, 2, 3, 4]"
   {1,2,3,4}.to_s  # => "{1=>2, 3=>4}"

4. Method#receiver and Method#owner

   class A; def foo; end end
   a = A.new
   a.method(:foo).receiver      # => #<A:0xa7c9f6d8>
   
   class A; def foo; end end
   a = A.new
   a.method(:foo).owner         # => A

5. Process.daemon

   Process.daemon()                        => fixnum
   Process.daemon(nochdir=nil,noclose=nil) => fixnum

6. Blocks can take block argument

   define_method(:foo){|&b| b.call(bar)}

7. Block arguments are always local

   a = 1
   10.times{|a| } # !> shadowing outer local variable - a
   a  # => 1

8. New literal Hash syntax

   { a: 1, b: 2 }
   foo(a: 1, b: 2)

9. Class variables not inherited

10. BasicObject

    BasicObject.instance_methods
    # => ["__send__", "funcall", "__id__", "==", "send", "respond_to?", "equal?", "object_id"]
    Object.ancestors       # => [Object, Kernel, BasicObject]

ちなみにGregoryが嫌いなことは

a = ->(b,c){ b + c }

だそうだ。これ不評だよねえ。でも、なんでだろう？

_ もっと失敗しよう：江島健太郎 / Kenn's Clairvoyance - CNET Japan

私もしばしば経験があるんだけど、 頭の中ではなにもかもうまくいって、「成功間違いなし」とか思っちゃうんだけど、 いざ実践してみると、逆になにもかもがうまくいかないように思えるなんてのは 日常茶飯事だよね。

私の息子は折紙が大好きなんだけど、 折り図を見るとかっこいい作品がイメージできてわくわくしながら 取り掛かるものの、いざ折り始めるとぜんぜんうまくいかなくて がっかりしてしまう(彼はちょっと挫折癖がある)のをしばしば見かける。

ま、親子だから分野は違えど似たような反応をしてしまうわけだな。

しかし、私の方はそのような失敗の経験をはるかに積んでいるために まだ若い息子よりも立ち直りが早いし、そもそも失敗を予測して手当てをすることができるように なっている。

江島さんがリンク先のエントリで書いてることって、 結局はそういうことだよね。やりもしないで「やりさえすれば成功間違いなし」とか 「自分は天才だ」とか思いこんじゃう、ちょっと(だいぶ？)アレな人と 根っこは同じだ。

いや、程度の差こそあれ、人間、誰でもみんなアレなんだよ。 要はそこで(何度も失敗しても、それでもの)一歩踏み出すかどうかが、 違いを生むんじゃないかなあ。

ちなみにRubyは私の最初の言語ではない。

_ 「Google デスクトップ」のLinux版が公開 | パソコン | マイコミジャーナル

公開された。オープンソースでないのが気に入らないが、 とりあえず使ってみることに。

しかし、いつまでたってもインデックス作製が終わらない。 このペースだと数週間くらいかかりそう。

_ [言語] steve dekorte - Dynamic vs Static Programming

Ioの作者、Steve Dekorteによる動的プログラミング対静的プログラミング。

動的プログラミングには静的プログラミングにはできない柔軟性があるが、 それには動的プログラミングの流儀(or 文化)に従う必要がある、という話。

面白かったのはここ

For example, I worked at a Smalltalk consulting company for a while where I heard a horror story of a company that made the move from COBOL to Smalltalk but then proceeded to write all their Smalltalk code in COBOL style - one big class with all their old COBOL functions directly translated to Smalltalk methods. I suspect those COBOL programmers would claim Smalltalk wasn't any more productive, just as people that use dynamic languages but not dynamic design patterns would.

私は以前Smalltalkコンサルティング会社で働いていたが、 COBOLからSmalltalkに移行したある会社での「怖い話」を聞いたことがある。 その会社はSmalltalkで開発していたが、まったくCOBOLスタイルのままであった。 つまり、ひとつの巨大なクラスがあり、以前のCOBOLプログラムの機能が 直接Smalltalkのメソッドに置き換えられていた。 おそらく、COBOLプログラマは「Smalltalkに移行しても全然生産性が上がらないよね」と 不平を感じていたに違いないと思う。 動的言語を使っても動的デザインパターンを使わない人々と同じように。

で、Steveからのチャレンジは以下のようなもの(一部)。静的言語でこれが(簡単に)できるか。

• 動的にメソッド、オブジェクト、継承、名前空間を追加できるインタフェースビルダー。
• 巨大なスタブ生成を必要としない分散オブジェクトシステム。
• その言語だけで記述されたデバッガー
• バージョン問題などに悩まされないオブジェクトデータベース。
• 現在あるクラスだけでなく将来のオブジェクトに対しても動作するようなコード。

私の見る限り、Javaなどではこのような動的性質はXMLという別の動的言語を アプリケーションに組み込むことで実現しているように思う。 それはつまり「グリーンスパンの第10法則」ってことだよね。

_ [言語] The Future of TurboGears - TurboGears

次期TurboGearsはPylonとマージする、という話。

それがどういう意味を持つのか、私にはよくわからないけど、 フレームワークが進歩していくのは良いことだと思う。 互換性が必要な人たちは泣くかもしれない。

_ [Ruby] Rubricks Project - Rails/Ajax高速化関係メモ

Rubricksの経験から学ぶRails/Ajaxの高速化テクニック。 なんか結局はIE対策が中心。

IEでのJavaScriptプログラミングはなかなか大変そうだ。 2月に大西さんと話した時も嘆いていた。

_ [Ruby] Pivotal Blabs : Rails, Slashdotted: no problem

Railsで記述された特許レビューサイトPeer-to-patentが Slashdottedされたが、別に問題ではなかった、という話。Railsでも頑張っている。

鍵はキャッシュの工夫らしい。かれらはholeless cacheという独自テクニックを使ったそうだ。 シンボリックリンクを使ったキャッシュと言うのは珍しい。

_ [Ruby] 第11回　オブジェクト指向言語Ruby

島根大学講座「情報と地域〜オープンソースと地域振興」の第11回。

40人くらいいたかなあ。NHK松江放送局の人も来てたけど、 これいつの日か放送されるのかしら？

ま、情報を専門としない学生も半分はいるようなので あまり難しい専門用語などは使わないように。 途中、Rubyの文法を解説するスライドも用意していたのだが、 聴衆の顔つきを見る限り、ついていけなそうだったのでその辺はパス。

反省すると、抽象的な話が多くて、辛そうにしている人がいたような。 もうちょっと具体的な例を持ち込むべきだったかも。 たとえば、コードの簡潔さの話をしている時には、 簡潔なコード例とか。

とはいえ、もっとも重視したい「気分」や「ノリ」は視覚化できないのが痛い。

次回は実際にRubyを使った演習を行うそうだけど、 なるたけ多くの人がついていってほしいなあ。 2回ほどRubyについて学んだ後は、前田くんによるRails入門。

考えてみると結構ぜいたくな講義だよな。

_ [言語] Useless Factor: The incomplete, would-be Unicode implementor's guide

スタックベースの言語FactorにおけるUnicodeの取り扱いについて。

かなりちゃんと調べていることがわかる。 で、内部表現としては固定長であることを重視してUTF-32を採用することにしたとか。 Unicodeに拘泥する限り、ある程度妥当な選択だと思う。

しかし、Factorでは将来codepoint単位ではなく、 grapheme(複数codepointから構成される「文字」)を取り扱うことを 想定しているようなんだけど、それって結局は可変長文字を取り扱わなくちゃいけない ってことじゃないんだろうか。それだったら内部表現にもUTF-8で十分のような。

ちなみにRubyでは、

• 内部エンコーディングはステートレスならどんなものでも選択可能
• (デフォルトの)UnicodeハンドリングはUTF-8
• UTF-16やUTF-32も扱えるようにしたい
• けど、スクリプトはASCII互換である必要がありそう
• ということはUTF-16やUTF-32のリテラルが書けないので大変そうだなあ

というレベル。graphemeに関しては、デフォルトでは扱わない。 けど、graphemeを扱うようなエンコーディングハンドラを書くことは可能だと思う。

_ オープンソース/C言語に学ぶ「ソースコードの読み方」：ITpro

ソースコードの読み方を身に付けることは重要だよね。

で、正直、ここ数日、こうやって自分の文章を読み返す機会が立て続いているわけだが、 実は私は自分の書いた文章がとても好みだということが実感できた。 自分の好きなように書いた文章だから当然だ、という気もするけど、 なんかナルシストみたいでイヤという気持ちも同時にある。

_ FPN-格差社会で生き残る為の５つの能力

「生き残るための」というよりは「良いデザインのための」という印象もあるが。 で、その5つの能力は以下の通り。

1. デザイン力
2. 商品・サービスの物語力
3. 新コンセプト構築力（新たな組合せを創造する力）
4. 共感力
5. 遊び心

偶然ながらRubyのデザインにおいて(結果的に)強調されている点とかなり似通っている。 言語そのものにはあまり「遊び心」はないような気がするけど。 コミュニティ(の参加者)にはたっぷりありそうだ。Poignant Guideとか。

_ [Ruby] christopher baus.net | 2007-06-02 | Rails is written in the wrong language

DHHが語る以下の言葉は、RubyというよりもむしろPythonの思想を連想させる。 ということは、RailsはRubyではなく、Pythonで書かれるべきではなかったか、という話。

Decisions are bad.

Because decisions take up your brain power, and it requires brain cycles to consider which or the other.

The more decisions you can take out of the whole the thing, the more brain power you free up to consider the really important things.

That's of course how this leads to simplicity. It leads to simplicity in the fact that it is not even something you think about anymore.

Constraints are liberating.

It [Rails] takes a stand on lots of issues.

If you design a new schema and you want to use composite primary keys you're insane. And basically if you want to indulge in insanity it should hurt. It shouldn't be a walk in the park to be insane...

うーん、どうだろうか。Railsはopinionated softwareと呼ばれる通り、 「私の言うことに従えば楽できるよ」と呼びかけてくるタイプのフレームワークだ。 しかし、そのクレージーな実装のためには open classみたいな機能が使いやすい状態で存在している必要があったんじゃないかなぁ。

つまり、opinionated frameworkを実現するためには、 それを実装する言語自身はopinionatedであるよりは、 むしろ上位層のopinionを受け止める柔軟さ(悪くいえばいいかげんさ)が 必要だったんじゃないかと。

Larry Wallの言うところの単純さと複雑さの関係と似ているよね。 言語が単純だとソリューションが複雑になるというアレ。

だから、Lisp on Railsは可能だったかもしれないけど、 Python on Railsは無理だったと思う。

とはいえ、DjangoとかTurboGearが頑張っているという話を聞くと、 まあ、そんなに「無理」と断言することもないのかもしれない。 聞くところから想像すると、やはり、Djangoとかちょっと「Rails的」ではないようだけど(悪いことではない)。

_ [言語] jessenoller.com - “Too many ’self’ in python.That’s a big flaw in this language.”

「selfが多すぎるのがPythonの欠点だ」と言われるけど、 なんでselfがそんなに嫌われるのかがわからない、という話。

まあ、ある言語に慣れ親しんでくると、その言語でもっとも頻出するものが、 意識下にもぐりこんでだんだん認識されなくなってくるような傾向があるのかもしれない。

• Lispの括弧
• Pythonのself
• Rubyのend
• Perlの$@%{}/

そう言われればそんな気がする。ゲシュタルト問題なのかもしれない。

とはいえ、今回も参照されている Zen of Pythonのひとつ「Explicit is better than implicit(明示は暗黙に勝る)」には反対だ。 明示的な記述は簡潔ではないので、「Succinctness is Power(簡潔さは力)」と矛盾する。

ふたつの原則のうち、どちらかを選べと言われたら、(私にとって)答えはひとつだ。 私の視点からはこの原則こそが「Pythonの最大の欠点」だと思う。

同意しない人は多そうだけど。

_ [Ruby] ［動画］うまくやればたくさんのプログラマはいらない − ＠IT情報マネジメント

えー、「たくさんのプログラマはいらない」なんて言ったっけ、 と思ったけど、どうやらほんとに言ってるようだ。 アルコールは入ってないけど、てけとーに放言しているからなあ、この時は。

一般論としてではなく「という局面もある」ということで、受け止めていただきたい、ぜひ。

とはいえ、「生産性重要」というのは本当。

_ 嘘か誠か？元社員が明かすグーグルの職場環境と待遇:ニュース - CNET Japan

別にフツーだと思うけど？ というか、このリークがMicrosoftから来たということを考えると 「Googleは理想郷ではないよ」ということが言いたいのかもしれない。 が、そんなのは当たり前で、勝手に妄想を膨らませる方が悪い。

むしろ、リーク元のMicrosoftの職場環境と待遇を考えると どうなのか、と思う。 特に私にとって重要なオープンソースソフトウェア開発者としての暮らしやすさについて。

で、その観点から考えると私は絶対にMicrosoftでは働きたくない。 私にとってGoogleは理想郷ではないけれども、Microsoftは...ちょっと...(言えないことがあるらしい)。

_ [Ruby] 情報処理学会論文誌プログラミング No. SIG.10(PRO 33)

出張やらなにやらどたばたしている間に届いていた論文誌を読む。

ささだくんの論文「Ruby用仮想マシンYARVにおける並列実行スレッドの実装」が 掲載されている。私と前田敦司先生、並木先生も共著者に名前が載っている。

で、前から読んでいたこの論文はおいといて、 発表概要だけで論文掲載にいたらなかった「世代管理を保守的に行う世代別GCアルゴリズムの提案およびRubyへの実装と評価」というのが非常に気になる。

アブストラクトによれば、

本発表のアルゴリズムの特徴として、ライトバリアが必要ない、 メジャーコレクションとマイナーコレクションが一体化している、 および生きているオブジェクトの移動を必要としない ことなどがあげられる。

のだそうだ。うーむ、どうやって実現しているのだろう。 アブストラクト中でのヒントはこれだけ。

先頭側の領域をold領域、末尾側の領域をnew領域に分断し、 old領域に属しているオブジェクトはすべて古いオブジェクトと見なす 新しい世代別GCアルゴリズムを提案する。 本発表のアルゴリズムでは、old領域ではnew領域へのポインタが存在するかを検査し、 new領域ではGCを行う

のだそうだ。うーん、オブジェクトの移動を伴わないのに どうやってnew領域とold領域を分断するのかな。

そうか、アレか。木山版みたいにリンクリストで世代を管理してるのかな。 で、old領域のオブジェクトにはマークビットを立てたままにしておけば、 old領域のそれぞれのオブジェクトから 再帰マークするだけでold領域からnew領域のリファレンスを検出できるよな。 後は普通にルートから再帰マークを行い、 new領域に属するオブジェクトだけをスイープすればよい。

メジャーコレクションしたい場合には事前にold領域のマークビットをクリアしてから GCすればよいことになる。 もちろん、メジャーとマイナーの切り替え戦略とか、 検討すべき点はいくつかあるだろうけど、そんなに悪くないアイディアのように思える。 意味があるかどうかわからないけど、複数世代への拡張も可能だし。

では、このアイディアが論文掲載に至らなかった理由はなんだろうか。

• 性能改善が「全体の実行時間が最高90.8%、1回のGC時間が最高70.8%に短縮」とあるが、 全体で9.2%、GC時間で29.2%の短縮ではさほど効果がないと思われた(ちょっと考えにくい)
• アブストラクトでは示されていない測定したベンチマークが不自然なものだった
• 最高の改善はレアケースで、通常のケースでは変化なかった(あるいは悪化した)
• アブストラクトには書いてない欠点があった(メモリ効率が極端に悪化したとか)
• その他

まあ、GC時間が30%近く改善されたらすごいと思うけどな。 もっとも、ここで示した方法では「メジャーコレクションとマイナーコレクションが一体化」は 達成できていないような気がするので、また違うアルゴリズムなのかもしれない。

とか書いてると、作者からコンタクトがあるかも。 神奈川工科大の五百蔵(いおろい)さ〜ん、見てますかぁ？

追記

さらに考えてみた。

あるGC時点で存在するすべてのオブジェクトの総数をm、 old領域に所属するオブジェクト数をo、 new領域に所属するオブジェクト数をnとした時、

m = o + n

であるが、ここで、old領域で「生きている」オブジェクト数をoL 「ゴミになった」オブジェクト数をoGとする。 new領域でも同様にnL、nGがある。

o = oL + oG
n = nL + nG
m = (oL + oG) + (nL + nG)

さて、ここでマークフェーズとスイープフェーズのコストを考える。 従来のGC方式ではマークのコストは、生きているオブジェクト数に依存するので

oL + nL

になる。また、スイープは全部のオブジェクトをスキャンするのでコストは

m (= o + n)

である。

この「世代別」方式でのマークのコストは、 (old→new参照を検出するため)旧世代オブジェクトから全部マークした上、 主にnew領域を対象に通常のマークを行うので、

o + nL

となる。スイープのコストはnew領域のオブジェクトのみになるので

n (= nL + nG)

である。

さて、これを元に旧方式と新方式のコストを比較すると、 マーク時のコストは

旧方式: oL + nL
新方式: oL + oG + nL

で、oGぶんだけ新方式の方が増加している。 経験則からoGは小さいことが期待されるとは言え、 マークコストの増加は痛い。

一方、スイープ時のコストは

旧方式: o + n
新方式: n

で、old領域をスキャンしなくてもよい新方式の方が優れている。

スイープはnew領域だけスキャンすればよいという点で、 有利だが、実はスイープは一気にやらず遅延するテクニックがあるので、 それを使えば差はほとんどなくなるかもしれない。

正確に結果を知るためには、実装して測定してみるのが一番だけど、 こうやって机上で考える範囲内では期待するほど有効じゃないかもな。

世の中甘くない。

_ [言語] picol, a Tcl interpreter in 550 lines of C code - antirez weblog

550行のCで実装されたTclサブセット。

Tclってのは小さな言語だが、550行ってのはすごい。 先日の(圧縮された)lisp500とちがってまともなコードで550行ということである。

勉強になる、かも。Tclが変な言語であることは置いておくとして。

picolのページには「Rubyなどで書いたら200行以下で実装できるだろう」とあるが、 Haskellで書いたTclサブセット(hiccup)は 250行だそうだ。

_ [OSS] Welcome to GPLv3 − GPLv3

とうとう出た。

自分で最終的な判断をするのは、これからGPLv3がどういう意味と影響を持つのか 見極めてから。それまでは、引き続きRubyのライセンスは独自とGPLv2のデュアル。

今の計画では、

• 独自とGPLv2のデュアル
• 独自とGPLv3のデュアル
• 独自とGPLv2とGPLv3のトリプル

のいずれかを考えている。最後のものは最終手段として、できれば避けたいものだ。

_ [言語] 新言語 Xtalを作る日記- インスタンス変数

Xtalではインスタンス変数は配列として持ち、オフセットで管理される。 一方、RubyやPythonではハッシュテーブルとして持ち、名前で管理される。

これは純粋にトレードオフで、 配列の方がアクセスは高速だし、インスタンス変数のタイプミスがコンパイル時にわかる というメリットもある。しかし、名前によるアクセスも 動的にインスタンス変数が追加できるので、 オープンクラスや特異メソッドに対応しやすいという利点がある。

で、リンク先のエントリでは、XtalとRubyとPythonでベンチマークを取っている。 インスタンス変数に対して加算するという単純なものだが、 結果は

• Xtal : 6.805秒
• Python (Python 2.5) : 8.457秒
• Ruby (ruby 1.8.6 (2007-06-07 patchlevel 36) [i386-mswin32]): 16.751秒

で、配列方式を取るXtalが一番高速であることがわかる。 っていうか、Ruby 1.8遅いな。

ま、配列アクセスの方がずっと高速だからね。

...と、言いたいが話には続きがある。 実はこの同じベンチマークをYARV(1.9)で実行したら、

• Ruby (ruby 1.9.0 (2007-06-30 patchlevel 0) [i386-cygwin]): 4.391秒

となった。つまり、どういうことかというと、 (少なくともこのベンチマークでは)インスタンス変数のアクセスコストは支配的な要因ではない、 ということだ。

パフォーマンスに必要以上に注目してしまうことも、 適切でないベンチマークを選んでしまうことも、 私も含めて多くの技術者が陥りやすい罠だ。

ベンチマークは奥が深い。