Arcがとうとうリリースされた。
現時点ではMzSchemeで書かれたSchemeへのコンパイラとして実装されているようだ。 チュートリアルを見ると 「簡潔な表現を重視したLisp-1」という感じ。 ふーん、Lisp-2じゃないんだ。
興味深いのは「~」と「:」。
「~f」は「(fn (x) (not (f x)))」を意味する。 「f:g」は「(fn (x) (f (g x)))」を意味する。 これらはより関数型プログラミングを強く意識していることを意味してるんだと思う。
あと、「lambda → fn」とか「defmacro → mac」とかは まあ単なる短縮形って感じ。「setf → =」ってのはちょっと意外だったけど。
で、さっそく批判されている。 「ビッグネーム」が6年越しでほのめかしてきた言語だけに 期待が膨らんでいたぶん、失望も大きかったらしい。 まあ、彼ほど忙しい人が自分で開発したんだから、 あんまり進まないのは当然だと思うよ。
さて、いくつもある批判のうち最大のものは 「ASCIIの96文字しか扱わない」というもの。 とはいえ、フルUnicodeをサポートするのは大変だし、 「とりあえず」という意味ではそんなに悪い判断ではないと思うよ。 むしろ下手にUnicodeべったりな処理系にするよりは賢いかも。 変に実装すると今さら「1文字=16ビット」で実装しかねないから。アメリカ人は。 逆に「1文字=1バイト」にべったりしてもらっても困るわけだが。
私にとってもっと大きな欠点だと思えるのは、 オブジェクト指向機能あるいはgeneric functionが導入されていないこと。 まあ、Arcがオブジェクト指向言語でない理由はPaulがすでに述べているわけだが、言語の拡張性や柔軟性を考えるとgeneric functionは欲しかった。
あと、Lisp-1にCommonLisp的マクロシステムを導入しているような気がするんだけど、 これって安全に書けるんだっけ。よく知らないんだけど、 Schemeの人々がR5RSの時にマクロシステムでさんざん悩んだのはまさにそこにあった ような気がするんだけど。この辺は識者に聞いてみたいところ。
ここで説明もなくLisp-1とかLisp-2とか書いたが、 そういえば日本語であまりこの用語を見たことがないので補足しておく。
基本的に名前空間が一つしかないLispのことをLisp-1と呼ぶ。 たとえばSchemeがそう。関数の名前空間と変数の名前空間か分離していないので
(display "hello world") ;; (1) hello world (define p display) ;; (2) displayをpに代入 (p "hello world") ;; (3) 1行目と同じ動作
となる。一方、名前空間がひとつでないLispをLisp-2と呼ぶ 別に名前空間の数はふたつに限るわけではない。CommonLispでは7つと聞いたような気がする(本当？)
(print1 "hello world") ;; (1) hello world (setq p print1) ;; (2) undefined variable print1
CommonLispでは関数の名前空間と変数の名前空間が異なっているので、 上記の代入はエラーになる。
Lisp-1とLisp2の区別はLisp以外のプログラミング言語でも存在する。 たとえば、PythonやJavaScriptはLisp-1であり、 RubyはLisp-2である。
どっちが良いとかは難しいが、Lisp-1の方が関数型プログラミングを 統一的に書きやすいというメリットはある。 一方、伝統的なオブジェクト指向プログラミングモデルにはLisp-2の方が なじみやすいだろう。
「なめねこ」まで引っ張り出すとは。なんか私が前フリをかましたように見えるけど、 先日の「Webアプリケーションをなめるな」の元ネタは 「月をなめるな」ですからね*1。
ちなみにこの研修、うちの娘の参観日でも行われていた。 が、中学生たちはちゃんと月について理解してたようだ。 少なくとも「酸素ボンベは要らない」などとは言わなかった。
*1 正確には「はっきりと意識はしてなかったけど、あえて言えば」くらいだね
意外な展開。見守りたい。
これがどういう意味を持つのかは 内部事情を知らない私には断言するのは難しいけれど、 オープンソースをはじめとした技術(未来技術？)に価値を見いだす企業が増えており*1、 お金に余裕があれば会社を買うことでその技術を入手しようという行動が 少なくとも海外では目立っており、 この買収は国内でもその動きが出てきてい兆候なのだ、 とも読める。
そうなんだろうか。
*1 最近の例だとMySQL, Trolltechなど
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に移行する動機づけは不十分である。 まあ、現時点ではそういう働き掛けも受けてないし。
サイトが公開された。プログラムとかはまだ埋まっていない。 あと、３ヶ月ほどなんだけどなあ。
ささだくんも行くみたい。
先々週まで「お母さんといっしょでないとプライマリーのクラスに出ない」と 駄々をこねていた娘は、先週からひとりでクラスに出れるようになった。 ちょっとした動機づけと、それによる「良い行動」をさんざんほめてやったのが 原因のようだ。ポジティブフィードバックが効いた、ということでもあるが、 いずれにせよ、聞き分けのある態度を見せるだけ成長してくれたのがうれしい。
「親にとって都合が良い」ことを喜んでる側面もないではないな。
先週、教会の大管長であるゴードン・Ｂ・ヒンクレーが亡くなったので、 彼の葬儀および埋葬が執り行われた。 その様子は衛星放送で中継された。
彼の生涯のダイジェストも放送されたが、 立派な人をなくしたのだと惜しむ気持ちが強かった。 もっともすでに９７歳にもなっておられたので、 これ以上激務を背負わせるのはいかがなものかとも思ってはいたのだが。
いくつかのことを改めて気付かされた時間であった。
一口に「初心者」と言っても、ただ単に経験が足りないだけの「真の初心者」もいれば、 「やる気」、「向上心」に欠けるので実力がいつまでも伴わない「自称初心者」もいる。 あるいは「真」と「自称」の中間に位置するとか。
で、やる気や向上心のない人は手のつけようがないので、ここでは扱わないことにする。
さて、初心者向け言語の話だ。
しばしば「初心者向けの言語」と宣伝される言語がある。 たとえば、BASIC, HSP, PHPなどがそれにあてはまるようだ。
これらの言語にはなんらかの共通項があって「初心者向け」と考えられている のだと思う。つまり、初心者にアピールする特質を抽出できれば、 その特質を他の言語に付与することも、あるいは可能かもしれない。
で、これらの言語の仕様(文法や組み込みの機能)について思い返してみると
というような感じに思える。PHPに関しては最近はオブジェクト指向機能も備えて Java化しつつあるけど、機能が関数ベースでフラットな点は依然として事実だ。 また、PHP使いには「関数化すること」や「オブジェクト指向機能を使うこと」への 抵抗感が強い人がそれなりに観測されるようだ。
ここから「初心者向け言語が避けていること」言い替えれば 「初心者が苦手なこと」が何であるかだいたいわかる。 彼らは「抽象化」が苦手なのだ。
関数がなければ、あらゆる機能はプリミティブの組み合わせをたどっていくだけで (原理的には)理解できる。ある意味、安心だ。
抽象データ型やオブジェクト指向機能のような新しい概念を 新たに学ぶときの複雑さの増加は、たとえば100ある基本関数にひとつふたつ新しいものを加える ような複雑さの増加に比べると敷居が高い。
また、20数年前のBASICプログラムを思い出したり、U-20プロコンにおける若者のプログラムを 見る限り、抽象度が低く(私のようなスレたプログラマには)理解が難しいような プログラムでも力業でなんとかしてしまうのが、初心者、あるいは経験の少ないプログラマ のようだ。
しかし、考えてみれば「抽象化」というのは、この半世紀にプログラミング言語が進化してきた方向そのものだ。 あらゆるプログラミング言語はそれぞれの方向でより高い抽象化を実現するために 進化してきている。
抽象化は
などなど、良いソフトウェアを開発するのにもはや不可欠な概念だと言ってもよい。
新たな概念を学ぶことを拒否して、初心者のままでいつづけるか、 抽象化を体得して脱初心者を目指すか、という究極の選択を迫られているような気がしてきた。
そういう観点からは、「初心者向け言語」の「初心者向けの性質」は 実は活用してしまうと良いプログラマーになることを疎外する危険性がある。
初心者にウケるために抽象化を強調しない言語があってはいけないとまでは 言わない。趣味のプログラミングであれば、良かろうが悪かろうが関係ない。 それなりに楽しければそれでよいんじゃないか。 が、良いソフトウェアを開発したい人は、むしろ積極的に抽象化機能を 学び、活用すべきだろう。特に職業的ソフトウェア開発者は。
初心者への間口を広くするために基本機能はフラットにし、 オブジェクト機能などを追加して抽象化もできる言語にすればいいじゃないか、 と思う人もいるかもしれない。
が、個人的にはそれはうまくいかないと思う。 そのような言語では学ぶことを拒否する「自称初心者」は いつまでも抽象化機能を身につけず、質の悪いプログラムを生産し続けるだろう。
もちろん、志の高い人はそのような言語を通じて抽象化機能について学び 使いこなせるようになるだろうが、 それくらい志が高ければ、最初から初心者にこびない言語を使っても 同じくらいか、もしかするとより短い期間で、良いプログラマに成長するだろう。
とはいうものの、初心者向け言語への要求があるのは事実である。 それを否定するつもりはない。
そのうちのいくばくかは、初心者向け言語から入門して段階的に(スムーズに)進歩できる という「誤解」によるものだろう。しかし、すでに述べたように 「初心者向け」という性質は、良いソフトウェア開発に必要な性質とある程度矛盾する。
とはいえ、最大の原因はプログラマにはないのではないか。 間違っているのはプログラマじゃない、社会が間違っているのだ。
どういうことか。
私がなにか大きな買い物をするとしよう。 平均的サラリーマンが購入する一番高額なものといえば住宅なので、 家を買うことを考えよう。 新築であれば、土地と建物で3000万とか4000万とかかかるのではないだろうか。
では、私はこの家を素人に立ててもらいたいだろうか。 現場に行ったら職人がどれもこれも、専門教育も受けていません、修行もしていません、 先月までは関係ない職業でした、とかいうような人の集まりだったら。
私はイヤだ。
が、ソフトウェア開発ではそれに近いことが平気でまかり通っている。 ソフトウェア開発現場には「自称初心者」がたくさんいるし、 そのような人でも開発に投入するために「初心者向け言語」が重宝される。
本当はそんな初心者を現場に投入してはいけないはずだ。 建築業界でもあまり良くない噂を聞くことはあるが、 それでもここまでではないはずだ。 ソフトウェアを設計するのに「建築士」のような資格は不要だし、 大工や左官に比べてソフトウェア開発者の技能のありなしを明確に判別する手段もない。
開発費用を値切る顧客、対抗に素人を投入するベンダー、 火を噴くプロジェクト、投入される火消し、 まわりの「素人」に足を引っ張られ抑圧ばかり高まる「できる」プログラマ。
まるでババ抜きのようだ。 「使えないソフトウェア」を引いて顧客が損するか、 「プロジェクト赤字」を引いてベンダーが損するか、 「消耗しきって体調不良」を引いて火消し開発者が損するか。
それでも「自称初心者」だけは、「私はわかりません」という顔をして生き残り、 ますますはびこることになる。
もちろん、そういう開発現場ばかりじゃないんだけどね。
問題提起だけで答えはないのだが、 「自称初心者の撲滅」と 「顧客のソフトウェア開発に対する意識向上」が 鍵だと思う。
もっともどちらも実現困難だよなあ。
2.6.18/2/2.6.23の使い分けから移行。 X.orgのintelドライバも動くし、サスペンド・リジュームの問題も解決したようだ。 ありがたい。これで一本化できる。
しかし、なぜかACPIからバッテリが見えない。/proc/acpi/battery が見えなくなっている。 gnome-power-managerやgnomeバッテリアプレットからはバッテリ容量が見えるのが不思議だ。
Hongli LaiによるMaking Ruby’s garbage collector copy-on-write friendly, part 7にあったパッチをベースにtrunkを変更してみた。
で、このパッチがなにをやっているか、という話。
Rubyが使っているGCは古典的なマーク・アンド・スイープGCで、 基本的アイディアは 「ルート」から再帰的に参照可能なオブジェクトに「生きている」マークを付け、 最終的にマークのついていないオブジェクトは「死んでいる」と見なして回収する、 というものだ。
この「生きているマーク」を付けるという作業がcopy-on-writeと相性が悪い。
最近のほとんどの(全部の？)OSはプロセスのコピー(要するにfork)を 行った場合、仮想記憶上ではメモリ空間をコピーしない。 同じ内容なんだからコピーするのは無駄でしかない。 とはいえ、プロセスの実行に従って、メモリは書き換えられるから 書き換えをOSが検出して書き換えが起きる直前にオンデマンドでそのページをコピーする ことでコピーを最小限にしようという発想だ。
それはいいのだが、これとRubyのGCが組み合わさると せっかくページ共有してコピーを抑制しようとしたのに、 「マークを付ける」ことによってすべてのオブジェクトが書き換わってしまう。 GCが発生した瞬間に結局Rubyのオブジェクトを含む全ページがコピーされてしまう。
そこで、このcopy-on-write friendly patchだ。
マーク・アンド・スイープGCにはオブジェクトごとの「生きているマーク」は必須だが、 そのマーク(フラグ)は必ずしもオブジェクトそのものに埋めこむ必要はない。 「生きているフラグ」を別の領域(ビットマップテーブル)で持ち、 マークによってオブジェクトを書き換えないというのが このcopy-on-write friendly patchの原理だ。 GCによるオブジェクト単位での更新がないので、 forkしても本当に書き換えられなかったページはコピーされないまま共有される。
とりあえず動いているみたい。
「20%性能向上*1」とうたっていたのだが、 手元ではそんなに性能が変化するプログラムはなかった。むしろほんのちょっと遅くなる感じ。 ま、forkとか使ってないから当然といえば当然だろう。 キャッシュがとか思ったけど、考えてみればキャッシュは読み込みに効くので、 書き込みの局所化を発生させる今回のパッチは関係なさそう。
誰かforkとGCの組み合わせが原因で遅くなっていることが観測できるベンチマークとかもってないだろうか。 Ruby単体で動き、Railsとかとの組み合わせでない方がありがたい。
自分で試してみたい人はcow-friendly-gc.diffを どうぞ。
パッチを当てるためには
patch -p1 -lU < cow-friendly-gc.diff
とすると良いだろう。
*1 よく見たらpart6のパッチと比較して、だった
宣伝。
2月23日(土)に鳥取県鳥取市の鳥取環境大学で、 「セキュリティキャンプ・キャラバン with プログラミング -鳥取-」が 開催される。
残念ながら私は参加できないが(ちょうど帰国の日だから)、 斎藤先生や、wakatonoさん、竹迫さんのような有名人も来るし、 時間の都合が付けられる人はぜひ参加すると良いだろう。
ってか、なんで私の都合の悪い日にするかな(苦笑)。
私のエントリから派生していろんな人が自分の思うところの「初心者用言語」について 語っている。しめしめ。
あ、そうそう、そのエントリでひとつだけ訂正。
ここから「初心者向け言語が避けていること」言い替えれば「初心者が苦手なこと」が何であるかだいたいわかる。彼らは「抽象化」が苦手なのだ。
誰も突っ込まなかったのが不思議だけど、「初心者向け言語が避けていること」と 「初心者が苦手なこと」はぜんぜんイコールじゃない。 だから、正確には
のどれかだ。結構重要な違いだよね。
さて、いろんな人が初心者向け言語について書いてくれた中にはやや自虐的なものも見られる。
初心者こそPHPを使うべき - 行き詰まった時の気分転換日記
他の言語なら、きっと物知り顔のベテランが出てきて、あれこれ言うんだろうと思う。PHPはそれがない。だってみんな初心者ですから。
初心者には、枯れて面白みもない言語より、PHPのような激しく変化している言語の方が楽しいと思う。
PHPはそれだけ勉強しないといけない言語、まさに初心者にはもってこい。
最もタフになれる「初心者用言語」は Squeak Smalltalk！ - sumim’s smalltalking-tos
なにもそこまでいじけなくても。PHPもSmalltalkも良い言語ですよ、きっと。
そういえば、どのような言語が初心者にもっとも良いかについて、 私の意見は述べてなかった。 私の意見は、以下の通り。
言語は関係ない
ひとことに初心者といっても玉石混淆なので、なんとも言えない。 学ぶ気のある人なら、PHPから入ってもCから入ってもLispから入っても 抽象化やらオブジェクト指向プログラミングを身につけるだろう。 今３０代、４０代くらいの技術者はほぼ全員BASICとかFORTRANとかCOBOLの ような抽象化機能に欠ける言語から入門してるけど、 だからといってほとんどが抽象化を身につけてないというわけじゃない。
しかし、抽象化機能が強力だったり、使わないとろくにプログラムが書けないような言語で 入門した場合、それを身につけそこなう確率が下がるというメリットがある。 一方、現実に抽象化機能を身につけそこなっている人が数多く観測される以上、 そのような言語での入門手段しかない場合、そのような人が プログラミングそのものからドロップアウトすることになる可能性が高い。
私はそれでもいい(質の悪いプログラムを量産されるよりはマシ)と 思ってるけど、世間的にそれで合意ができるとはちょっと思えないな。
でも、「関係ない」ってのは、ちょっと卑怯な答えだよね。
先日、Microsoftで開催されたLang.NETの 結果を受けて、Ruby.NETの開発が中止されたとのこと。
今後、.NET上のRuby処理系はIronRubyに一本化される方向、らしい。
道本さんによるITPro Expoのまとめ。
どうなんだろうね。私のプログラミング人生における目標はお金持ちになることではないので、 適当な役割分担は適切だと思うし、その立ち位置は関係者にはかなり理解してもらえていると思う。 でないと、路頭に迷うわけだし。
はてなブックマークで私の日記のエントリを見ると、 この記事への宣伝リンクが入るのだが、 それは「お前のPHP関連のエントリは失言だ」と、 はてなに認定されている、と。
そういうことでいいのか(笑)。
新しいWebアプリケーションフレームワークRuby Waves。
Waves is feature-rich, compact, and extensible. Waves is thread-safe, hot-patchable, and supports easy clustering. Waves relies on best-of-breed Ruby libraries, including Rack, Mongrel, Sequel, Markaby, and Erubis, among others. And it uses just-in-time class and module creation to minimize the code you have to write.
MerbといいWavesといい、ポストRailsを狙っている(？)フレームワークが登場することは 大変健全なことだと思う。競争のないところに発展はない。
複数選択肢があるということはマーケティング的には善し悪しなんだけどね。
「動的言語批判」への批判。一読あれ。
ちょっと読んでみるとわかるけど、 この批判って単なる「静的言語が優れている」という意見への批判を越えていて、 実は批判の対象は「単一の言語しか知らないユーザの思い込み」ではないかと。
単一言語脳の恐怖
というか、なんというか。
ひとつしか言語・環境を知らないと、 それがすべてであり最良であるとしばしば思い込む。 そりゃひとつしか知らなけりゃ、それが最良だよね。 で、知りもしないくせに他の言語・環境に噛みつく、と。
ぜひ、プログラマ諸氏には、複数の言語・環境を経験していただきたい。 たとえ仕事に直接使えなくても。とくに両極端な選択がいいな。
「CとRuby」とか、「JavaとLisp」とか、「EclipseとEmacs」とか。 「ForthとScheme」とか。「HaskellとC++」とか、「APLとPerl」とか。
目の前の席の同僚(特に名を秘す)がイスをバランスボールに置き換えた。
ま、それはそれでよいのだが、 スクリーンの向こうで彼の背中が上下にゆらゆらと揺れると 普段のイメージとのギャップもあいまって なごんでしまって、しょうがない。
あ、なごむんだから、いいのか。
バグを直してもらうためにバグトラッカー(Trac)に懸賞金機能を追加するプラグイン、 Fund-a-bugについて。
以前、このようなものを夢想したことがある身としては、 大変興味深い。ただ、多くのオープンソースプロジェクトは 無償の奉仕だからこそ動機が維持できている側面もあるようで、 このようにお金が絡んだ時に、それがプラスに働くばかりではないように思う。
Rubyでも似たような仕組みを導入して (私以外の)開発者がおこづかいを稼げるようになったら どうなるだろう。喜ぶ？
それともやる気がなくなる？
その辺は実際にやってみないとわからないわけで、 そういう意味でも Fund-a-bugの今後の 動向に関心がある。
Rails作者DHHのコラム。 「よく経験何年って言うけど基本的に無意味だよね」という話。
新しい技術を学ぶ過程で学習曲線ってのは(曲線ってぐらいだから)、 線形にまっすぐ伸びることはなく、ある程度まで急激に伸びてから その後は停滞する傾向がある。DHHの経験だとサチるまでの期間は だいたい半年から1年ってところか。
だとすると、求人などでよく見かける「経験n年」はnが2以上の時に無意味だろう。 単に経験が長い人材よりは、むしろ新しい技術をより短い時間で身につける 「活きのいい」人材の方がよっぽど価値がある。
「一生勉強」というような職人ならともかく、IT技術に関して年数を問うのは馬鹿らしい。
もっとも、Ruby経験10年以上の技術者となれば、それはそれで欲しい人材ではあるが。 Rails経験10年以上という技術者がいたら追い返すけど。
是非にと依頼されたので、高校の授業で話すことにする。 情報電子科2年40人弱の前で話す。 高校で話すのは初めてだ。
正直、プログラミングについて専門にやっている科ではないので(組み込みが専門らしい)、 Rubyの話をしても通じないだろうなあ、と普段以上に準備に苦労する。 いつものが使いまわせれば楽だったんだけど、 今回は結局ほとんど新作になってしまった。 ビットやバイトから話すという基本的なもの。
最初からいきなり寝ている人も居たりするのだが、 興味を持って聞いてくれてる人もいるみたい。
聴講している大人もいたのだが、 むしろそっちの方に評判が良かったようだ。 生徒たちはどう感じたのだろうか。
教会の活動で。 延々とたこ焼きを焼き続けた。 数回繰り返すうちに技術が向上した。 大阪の人たちはみんなたこ焼きにこだわりがあるって本当だろうか。
私も一応大阪生まれなんだけど。
しかし、私が生姜が駄目だということばみなさんにバレてしまった。 味覚が子供なもんで。
っていうか、子供なのは味覚だけじゃないんだけど。
Sun JVMの新しいGCアルゴリズム。[論文PDF]
要するに世代別GCにおいて「若い世代」を重点的にスキャンする代わりに、 複数のセグメントでもっともゴミが多いものを最初にスキャンするという戦略、らしい。 で、なぜどのセグメントにゴミが多いかわかるかというと ライトバリアで監視しているということらしい。
ライトバリアのコストが十分に安くて、 exact GCが実現できる環境であれば、 これはアリなアルゴリズムだな。
GoogleはGFSとかMapReduceとかBigtableとかは 公開していない。差別化の本質だと思うので 公開されてないことについて文句を言う筋合いではないのだが、 とはいえそれと似たようなものがほしいことはある。
「なければ作ればいい」ということで、ふたつほど見つかった。
両方ともHadoopの上で実装されているようだ。まだ評価はしてない。紹介だけ。
Beautiful Codeの日本語版がもうすぐ出る。 久野先生ご夫妻が翻訳なので、内容については心配要らない、と思う。 まだ読んでないけど。
で、問題なのは私の部分。 この文章は
なのだが、これを日本語に戻すと、下手すると 「Rubyist Magazin出張版のコラム」がそのまま再現されてしまう。
ま、それでもいいんだろうけど。
が、個人的にはそれでは気に入らないので、 書き直すことにした。
が、時間に追われてしまって、あまり大々的には直せなかった。 結局、似たようなものになってしまったな。
0471941484 悪いこと(？)は重なるもので、ちょうど日経Linuxの〆切も重なってしまった。 こちらは、ガーベージコレクションについて。 発売されたばかりの３月号でも GCについて触れたのだが、どうも説明が足りない気がして、 各種GCアルゴリズムの利点・欠点なども含めて再度まとめてみた。 手ごろなサイズの日本語の解説があまりないような気がするので ある程度資料的な価値はあるだろう。
みんなに0471941484を薦めるわけには行かないしね。
でも、普段に比べて難解になりすぎちゃったかなあ。 あまり反省はしてないが。
Perlが2038年問題を 解決した、という話。
基本的なアルゴリズムは
というもの。もちろん、政治的に決まるDST(夏時間)には対応不可能だが、 未来のことは誰にもわからない(ので対応は期待されない)ので 大丈夫。
Rubyも同じやり方で対応しようかなあ。 でも時間関数にはトラウマがあるので(DSTバグでえらい苦労した)、 あまり自分ではやりたくないなあ。
誰か手をあげてくれないかなあ。
タイトルの通り。それって結構画期的な気がする。
JRubyでも似たような技術を使って、MRIの拡張を呼び出せるといいんじゃないだろうか。
もっとも彼らは、MRIと同じ機能を実現するために
するようなパワフルな人たちなので、そんなものは要らないのかもしれないけど。
なんか昔オープンソースマガジンに書いた記事が、 まわりまわってIBM Developerworkに出ているな。 なんにも知らなかった。
ま、ITmediaには仕様許可を出した覚えがあるので、 そこからDeveloperworkに出たんだろうな。
ま、せっかく書いた文章が再利用されることは良いことだ。
なんか昨日、〆切まぎわで(っていうか日経Linuxは〆切すぎてた)で 無理したので体調が悪い。
日曜学校は福千年について。
あと、一部の感情の行き違いについて話を聞いて、帰る。
くたびれた。
4756132545 原点に戻ることも、徹底的に納得するまで理解することも すばらしいことだと思うけど、 「Rubyの原典」として9年も前の 『4756132545』をあげられると どうしようか、と思う。
対応バージョンは1.4だし、 あれからRubyも私も成長しているし。
っていうか、もう絶版なのはいいとして プレミア価格14,800円ってのはどうなのよ。
新しい版を書くべきなんだろうな、本当は。 そんなパワーはないわけなんだけど。
と思ったら高橋さんが似たようなことを書いていた。
現代における原典としての価値はよくわからないけれども 私のところにはたくさん余っていて、 去年の引っ越し以来箱に詰まっている(結局は使ってない)本が たくさんあるので、 読者プレゼントにしようかなあ。
「お菓子を作りたい」という次女には留守番させて、 残りのみんなでスケートに行く。
３才児にスケートができるのか、と思ったのだが、 氷上で一人で立てる程度にまでは上達した。びっくり。
長男はイメージ通りには滑れず、ちょっと悔しそう。 まだ二回目だから。 シーズン中何回か滑れれば違うと思うんだけどねえ。
なんとなくアクターモデルを思い出させる。 Fairyの実行モデルの基礎にできる、かも。
先日に引き続き、某雑誌のためにライターさんから取材を受ける。
「クリスチャンとしての私」と「プログラマ(言語デザイナ)の私」の関係に 関心を持たれたようで、かなりの時間を教会とかの生活について 話す。そういえば、こんなに教会関係の話を(教会員でない人に)話すのは久しぶりな感じ。
宣教師時代の経験とか。
宗教って微妙な題材だと思うんだけど、いいのか？ 私としては、これも私の重要な一部なので、ありがたいと思ってるけど。
妻にも電話で取材をしていた。 内容は聞かなかったのだが、後で聞いたところ、 「彼は『4840196832』のトニーに似ている」と 言ったのだとか。確かに最近その本読んだっていってたな。
そうなの？
私、生粋の日本人なんだけどな。いや、日本人的でないところもあるか。 空気読まないこととか。
昨年、宮崎で行った人工知能学会での講演をご覧になっての感想。
プログラミング言語Rubyは、プログラマーに「自然なコーディング」を許容するために設計された「人工知能」なのだ、と。
どこでどういう省略記法を許すか、という規則を実装したパーザーはルールベースで作り込まれているはずなので、言語を作っている側は人工知能だと思わないで作っているのでしょうが、実務の文脈でいかに自然な記述を許容するか、一つ一つ職人芸で仕様を選択した結果は、「高度な手作り人工知能」と言えるのかも。
人工知能としての自然言語処理技術では「人間がやりとりする言語のコーパスを集めて、それをどう処理したらいいか検討する」ということが行われるわけですが、「プログラミング言語が使われるシステム開発の現場のコーパスを集めて、それを効率よく記述できるプログラミング言語を設計する」ということがもしきちんと行われたら、Ruby のような言語はもっと工学的に設計できるのかも知れません。そのときに重要なのは「集めるコーパスにリアリティがあること」ではないでしょうか。
そういう発想はなかった。Rubyは人工知能なのかあ。
東京へ。
雪で飛行機の出発が1時間ほど遅れる。 出雲空港はわりと雪に慣れているので、1時間も遅れるのは珍しい。 おかげで約束に遅れちゃったけど。
目黒の雅叙園に移動。
まずは、『BeautifulCode』日本語訳を記念して、 販促のために翻訳者の久野先生と奥様と対談。 最近は知らない人の方が多いかもしれないけど、 久野先生は日本を代表する言語屋で、 私の師匠筋の人である。
以前にも書いたけど、 Rubyの言語設計にも多少影響を与える記事を書いた人だ。
なもんだから、対談はいきなりディープな世界に突入。 みんなついてこれるのか？
で、楽しいおしゃべりと、おいしい食事を堪能した後、 宿題をいただいた。「29章もっと書き足してほしいなあ、2週間以内に」。
....善処します。
その後、デブサミに移動。 講師控室に行ったら、 「今、Joel Spolskyがいます。あいさつしますか」と誘われ、 あいさつに。
で、名刺交換とかした後、Wasabiの話に。で、Wasabiの持つ機能や、組み込みのテンプレート機能(PHPのちょうど逆)や、 ひとつのコードからクライアントサイドのJavaScriptとサーバサイドのPHPの両方を生成する機能などについて 詳しく聞いた。彼の直筆のメモは宝物にしよう。今日はディープな話が続く。
次に、Microsoftの波村さんと対談のための打ち合わせ。 急遽、高橋会長がコーディネータを務めてくださることに。
で、波村さんもたいがい言語好きな上に、 日々言語デザイン(と実装)で苦労しているので、 話が弾む、弾む。実際の対談もそうとう聴衆置いてきぼり感があったけど、 前後の控室の話なんか、誰がついてこれるのって感じ。
しかし、「マイクロソフトの中」での言語デザインというのは 我々オープンソースコミュニティでのデザインとは全然違っていて 興味深かった。
週三回のデザインミーティングとか。
いろいろな制約と挑戦とか。
後で波村さんに「Rubyをお休みして半年くらいマイクロソフトにインターンに行こうか」とか 話したのだが、実は半分は本気だった。しがらみがなければ、もうちょっと本気だったかも。
とにかくディープな1日であった。
夜は広尾に移動して、両親のところに泊まった。
昨日が最終セッションで日帰りできず、 明日は別件で前泊が必要だったので、 今日は東京で過ごさざるをえない。
午前中、広尾で教会の用事をすませて昼食を両親と取り、 午後はデブサミへ。
特に見たいと思っているセッションがあるわけではないので 展示を中心に。
Pythonのブースでは、
柴田さんから「『たのしいみんなのPython』にサインしてください」と依頼される。
Guidoのサインの下というのもどうなんだろう。
一部で価値が出るのかもしれない。
ついでに(？)、PHPブースではPHP本にサインする。 フレンドリー。
デブサミ会場で、雑談していると「PythonはDISらないんですか」と柴田さんから。 なんか自虐的じゃない？
とは言うものの、Pythonは基本的に良い言語で、 不満な点はかなり微妙だ。一般人にはどーでもいいような点だと思う。
一応リストを。
list comprehensionはLINQにつながる「イヤらしさ」がある。 「俺の言語を汚すな」って感じ。
[x for x in ary if cond(x)]
ってのはわからないでもないけど、
ary.map{|x|cond(x)}
の方がすっきりしている、と思う。
もっとも、波村さんによると、 このブロックを積み重ねる方法ではJOINが書きにくいというのが LINQ導入の理由だったそうなので(Andersは最後まで抵抗したとか)、 RubyでもJOINへの要求で、そういうようなことにならないとは言えない、かもしれない。
−− 大物ハッカーといえば？
Rubyのまつもとゆきひろさん。ハッカー理想像を実践されているところにあこがれます。技術力だけをみれば、まつもとさんより優れた方も多く存在されるかもしれませんが、日本人であそこまで自分の信念を持って行動されるハッカーってなかなかいないんじゃないかなと思いますし、自分でしっかりとしたコミュニティーを運営されていることなどもリスペクトしています。Ruby 1.9で過去の遺産をバシバシ捨てているのは素晴らしいなぁ。ああいう覚悟がC++にあれば、もう少し違っていたでしょうが。
いやあ、ほめられちゃった。 でも、そんなに信念持ってたかな。
それはそれとして、過去の遺産ってのはなかなか難しい問題で、 Rubyでもやっぱり苦しんでいる。 「バシバシ捨てて素晴らしい」っていうよりも、 ちゃんと互換性を維持する能力が足りない、ような気がする。
えーと...、女性から見てギークに魅力があるって話は 残念ながら他で聞いたことないなあ。 例外中の例外の話、なのかな。
あえて魅力に感じられそうな点といえば
くらいかなあ。一方、
とかのネガティブ要因もあるし。
まあ、どっちにしても個人に帰属する要因が大きいので、 ギークだからどうこうということは必ずしもないだろう。
根っからのオタクの私だって、結婚して子供までいるわけだし。 弾さんもそうだ。
もっとも、女房子供以外からモテたためしがないのだが。
楽天で米澤先生による講義が開催される。
米澤先生といえば、私が幼いころ(高校生くらい？)、 オブジェクト指向に関する情報が欲しかったけど 当時入手できる日本語の情報が、岩波の『算法表現論』くらいしかなくて、 苦労して借りてきて読んだのが私の原点になっている。
その先生とこんなに親しくお話しできるというのは なんとありがたいことなのだろうなあ。
はてなが京都に帰る、というお話。
いや、デブサミの講師控室で「なおやさんが京都へ引っ越し」とかいう話を 耳にしていたのだが、このニュースとつながるまでちょっと時間がかかった。
にぶい。
「東京じゃないところ」がどれだけのアドバンテージになるのか、 あるいはディスアドバンテージになるのか、注意深く見守りたい。
はてなにはすでにそこそこの人材がいるので、うまくやれば、 「毎日開発合宿」のように開発が進むかもしれない。 「普通の会社(NaClも含めて)」では、なかなかそれは難しいのだけど、 はてなはそういうのができそうな会社であるような気がする。
とうとう公開された。 OSS化に伴ういろいろと面倒なことをクリアした関係者の方に 純粋に敬意を表したい。
とりあえず島根県では使い物になっているが、汎用性などについては 改善の余地があると思う。できるものならばこのCMSを中心にしたコミュニティが 形成されて、発展するサイクルが成立すれば、と思う。
それはそれで難しい課題は山積みなんだけど、それでも、なお。
IoでObjective-Cの文法を導入する試み。
こういう「クレージー」なことができる言語は素晴らしい。 が、日常的に使いたいかどうかはまた別問題である。
John McCarthyがRubyに言及したのかっ、と思ってインタビューのログを読んだが、 インタビュアーがふっただけなのね。そりゃそうか。
で、返答は当然(？)ながら
I don't know enough for example about Ruby to know in what way it's related to Lisp. Does it use, for example, list structures as data. So if you want to compute with sums and products, you have to parse every time? So, in that respect Ruby still isn't up to where Lisp was in 1960.
というもの。ある意味、予想通り。
未来の言語であるところの「Elephant 2000」というものがどういうものなのかよくわからなかった。
朝から雪で、教会から帰ったら家の前の坂道が雪で滑って登れない。 先に帰った妻は子供たちと一緒に雪かきをしていた。 子供たちはどちらかというと雪遊びをしていたんだけど。
しかし、今年高校受験の長女は、勉強もせずに雪まみれになって 「滑ったり」、「転んだり」、「(溝に)落ちたり」していたのだが、 それはそれでいいんだろうか。
ところが、夕方になって妻が「寒気がする」とか言い出した。 どうやら先週の半ばに引いていた風邪が治りきっておらず 再発したらしい。
微熱と関節痛など典型的な風邪症状。 インフルエンザではなさそうだが。
あんまり具合が悪そうなので、 明日からのアメリカ行きは無理かもしれないと思った。 ただ、私が行かないとツアーの人に迷惑をかけちゃいそうなので 家族と仕事の都合の板挟みになって、精神的にかなりつらかった*1。
*1 結局、朝にはかなり回復していたけど
6時前に起床。成田でネットアクセスするためにワイヤレスゲート ヨドバシカメラオリジナルプランを購入。
朝、７時すぎに出発。 途中でデジカメを忘れたことに気がついて引き返す。 わりとぎりぎりの時間に米子空港に到着。 米子空港出発組と合流。
米子から羽田へ。羽田からリムジンバスで成田へ。 成田ではワイヤレスゲートのおかげで快適にネット。 夕方からUAでサンフランシスコへ。
サンフランシスコについたらまだ午前中である。
バスで梅田望夫さんのところへ。 祝日(Presitent's Day)なのに親切に対応していただく。 ありがたい。
いろいろなことについてお話したが、 同調圧力や「空気を読む」それから「多様性」について が中心的な話題だったように思う。
kuromomoさんがミーティングの内容を録音していたので、 どこかで(ITPro?)で公開されるのではないかと思う。
以前にインタビューを受けたものが公開された。 なんとなくRubyの宣伝っぽく聞こえるような書き方がしてあるが、 例によって本人にはそんなつもりは毛頭ない。
生産性とスピードがより重視される、というのが基本的な内容なんだけど、 「Web系に限定されるんじゃないか」と読む人も多いんじゃないかと思う。 少なくとも、「今」に限定して考えるとその通りだろう。 基幹系はWebのようには行かない。 また、現時点でRubyを基幹系に適用すべきとは考えない。
「できない」とは思わないし、実際に適用している人もいるんだけど、 Web系よりはずっと難易度が高いので、できる/できないの判断が自ら責任を持って行うべきだろう。 人に聞かないとRubyが適用可能か判断できない人には、まだ早い。
とはいえ、「今後」までを視野に入れると、 分野に関らずソフトウェア開発について同じような圧力は高まるだろう*1。 そうすると、「Web系以外は関係ない」話としておいて良いかどうかはちょっと疑問だ。
今後の業界変化の一方向として頭の片隅にくらいに置いとくのが良いのではないだろうか。
*1 SOX法など別方向の圧力もあるのは認識している
Macbook Airと同じくらい薄いThinkpadについて。 かっこいい。魅力的。 タッチパッドは要らないけど。
この間X61を買ったばかりなので、出たらすぐに、というわけにはいかないとは思うけど。 弾さんみたいに年に1台とかいうペースでは買わないし。
メンロパークにあるSunの本社へ。
オープンソース担当VCやらいろんな人の話を聞く。
今日会った有名人。
Ianに「Debian使ってるよ」と声をかけると、 返事は「ありがとう。私はUbuntuっていうバージョンのDebianを使ってるよ」というものだった。 って、Ubuntuかよっ。
情報交換をしたり、いろいろ。
私からもRuby Associationについてプレゼンを行ったのだが、 なぜか私のプレゼンの直前に通訳の人が帰ってしまい、 予期せず英語でプレゼンすることに。
つらい。
まあ、がんばりました。
昨年は寿司であったが、今回はアメリカ的な食事をとのリクエストが (Charlesから？)あったらしいので、McAuther Parkというレストランで 肉食。BBQがおいしかった。手がべとべとになっちゃったけど。
おなか一杯。
動的型の言語では以下のようなプログラムの問題を検出できない、という指摘
def test(a, b)
a + b
end
def main()
if ARGV.length > 3
test(1, test)
else
test(1, 2)
end
end
Process.exit(main())
まあ、それについては否定しないけれども、 だからといってこんな不自然な型不整合を検出できないという理由で 動的型が危険というのはかなりアンフェアな印象がある。
ただ、将来的にはカバレージツールやソフトタイピングの応用で 動的型言語でもより多くの問題を検出できるようになればいいなと思う。
プログラム言語に詳しい人あたりに感想を聞いてみたいなぁ。
Matzさんとか、派手にDISってくれないだろうか。
えーと、「言語をDISる人」としての認知が広がってきたのでしょうか。 本人としては「あらゆる言語ラブ」な人だと自任しているので、 ただ単にけなすことをイメージさせる「DISる」というのはちょっと辛いのだけど。
で、Curlについてはこの日記でも過去にいろいろ語っているのだけど(左上のボックスでCurlで検索)、 言語についてはあまり語っていなかったような気がする。
まず、Curlが関数型かどうかだが、 一昔前だと「関数」呼び出しがベースになっている言語はすべて関数型と呼ばれていた(Lispとか) ので、そういう観点からは関数型と呼べないこともないと思う。
しかし、現代で関数型といえば、副作用がない(少ない)、とか高階関数を基本にするとか のようなHaskellやOCamlのような言語をさすと思うので、 そういう意味ではCurlはあんまり関数型ではないと思う。
どうにもTclに近いんだけど、リストベースという点ではLispに近い。
Ingresの設立者であるStonbraker教授によるコメント。
SQLデータベースというのは過去の前提に基づいており、 現代においては時代遅れ。現代では別のやり方を考えた方がよいというもの。
Data manipulation, they said, can be performed with other tasks using languages such as Ruby. They describe a prototype DBMS called H-Store that embodies these ideas.
SQLのような完全に別の言語を使うよりもRubyのような言語を使ってやったほうがよいという主張のようだ。こんな文脈でRubyを見るのはうれしいことだ。
Rubyによるコミュニティサイト構築ツールEl Dorado。
Railsで作るのがあまりにも簡単なので、 なんでも自作しちゃう傾向があるのか、 PHPのXoopsとかDrupalのような「定番」に欠ける印象があるRubyだが、 それでもこうやって新しいものが出てくるような動きはあるようだ。
朝から団体さんでGoogleへ。 しかし、訪問するところがどこもシリコンバレーなのに 宿泊場所がサンフランシスコというのは無駄ではないのだろうか。
Googleにつくとさっそくプレゼン。 X61がXを立ち上げ直さないとプロジェクターを認識しないという問題があるのだが、 それ以外は快調。内容は昨年末の神戸での講演をベースに若干アップデートした上、 英訳したもの。神戸ではより少ない枚数で1時間話したような気がするのだが、 英語ではそんなに話せない。あんまり緊張したので時間を覚えていないのだが、 質疑応答をたしても1時間くらいか。
1.9のM17Nの実装について突っ込んだ質問をしてくるどこかで見たような人がいたが、 Guido van Rossumその人であった。
その後、Google Lunchをいただいた。Guidoも一緒に。
まず、Googleの料理だが、大変おいしかった。 個人的には日本的な味つけの楽天ランチの方が好みだけど。 しかし、空間の余裕はGoogleカフェテリアの圧勝。
Guidoとの会話だが、Unicodeの実装など技術的な話題や、 互換性の維持の運営などの話が中心であった。 終始フレンドリーであったことを報告しておきたい。 並んで写真も撮ったしね。
「Python 3.0のリリースが完了したら、次はどうするの」と聞いたら、 「引退する」とのこと。すぐに「冗談だよ」と言ってたけど、 後継者については考えはじめているようだ。 「最近参加した人に若いけど見込みのある人が(複数？)いる」、 「昔からかかわっている人は優秀だけど、役割が決まりすぎている(スペシャリストすぎる)気がする」と のことであった。ふむ、興味深い。実装と言語デザインではまた違ったバランス感覚が要求されるしね。
最後に、「Haskellみたいなブレースの使い方を採用する気ない？」と尋ねたら、 「いろんな文法の変更を試している人がいるから、その中のひとつとして考えてみる」という ことであった。これが実現したら大喜びする人も多いように思うけど(lambdaで複文が使えるようになるし)、 それほど乗り気であるようにも見えなかったので過大な期待は禁物である。
その後、伊藤忠アメリカの事務所でシリコンバレーの現状を聞いて(昨年とあまり変わってないような)、
それから、スタンフォード大学によってから*1サンフランシスコ空港へ。
さらにポートランドへ。
それからバスでホテルへ。 Hilton Portrand。なんで今回のツアーはHilton好きなんだ？ ネットアクセスはあいかわらず有料。次回はネット無料のところに泊まろうよ。 アメリカではそんなに多くないのは知ってるけど。
24時間$9.95とサンフランシスコよりは安い。けど良心的価格とはなかなか呼べないなあ。
*1 勘違い。実際にはスタンフォードに寄ったのは１９日であった
ちょうど私たちがスタンフォードに寄った直前にそこでビル・ゲイツが講演していたらしい。 ニアミス。
追記
NaClさんに指摘されたように、スタンフォード大学訪問は１９日。 ニアミスしたのは本当。
後で聞いた話なんだけど、今晩この地方では月蝕が観測されたらしい。 どうやら到着した時点ではちょうと全部隠れている時間だったらしく 全然気がつかなかった。惜しいことをした。
通常のCPythonでstackless threadを実現する拡張ライブラリ。
アセンブラを使ってるんで移植性は限定的だけど、 コンパクトだし、使いではありそう。 Rubyでも似たようなテクを使ってFiberとか実装するといいんだろうか。
後で本気でソースを読んでみよう。
ポートランドからビーバートンへ移動。
Open Technology Business Centerでミーティング。 なぜオレゴンがオープンソースか、などとかいうような話を聞く。
Linusをはじめとして意外な(？)有名人が ポートランド近辺に住んでいるとかいうような話であった。 Linusはあまり表に出ることが好きでないということだが、 よくいくコーヒーショップは知られているのだとか。
島根から来た人たちは、なんとか参考にできないかと思っているのか 大変熱心に聞いていた。
似ているところ
似てないところ
シリコンバレーよりはポートランドの方が島根っぽい？
でも、オレゴンの場合、オープンソースの背景にはIT産業が、 IT産業の背景には半導体産業があるわけで、 その辺は見逃してはいけないと思う。
そのほか、Rubiniusの話とか(なぜかポートランドにいるEngineYardのエンジニアから)、 Rubyをどう使ってるかとか、オープンソースがどうとか、 教育機関での取り組みとか。
Wikiの父、Ward Cunninghamも来てた。 Wardにあうのは久しぶり。2005年のOSCON以来か。 最近はaboutus.orgというサイトに取り組んでいるんだとか。
aboutus.orgは現在Mediawiki(PHP製)なんだけど、 段階的にRubyに移行しつつあるんだとか。
2001年に最初にWardに会った時には「Smalltalkに似てて良い言語だと思うよ。私は使ってないけど」 とのお言葉をいただいたのだが、それから７年、Ward自身がビジネスでRubyを使うようになるとは 時代も変わったものだ。
私自身もプレゼンしてくれという話だったので、 先日Sunでしたのと同じRubyアソシエーションについて発表する。 今回は通訳を付けてもらえたので日本語で発表したのだが、 途中からスライドは英語だし、通訳の人と英語で話したりしているうちに混乱してしまって 英語で話し出したり、ややわけのわからないことになってしまった。
あと、LUNARRの濱口さんが発表された。 高須賀さんは訪日中だそうで、残念ながらいらっしゃらなかった。 濱口さんは、なんていうんだろう、日本人的なところと、 全然そうでないところをあわせもったとても不思議な雰囲気を持った人であった。 この人が「やれる」と思ったというだけでLUNARRに期待できる。そんな感じがした。
後で、高須賀さんとも電話でお話する機会があった。びっくり。
OTBC関係者およびportland.rb(Portland Ruby Brigade)の合同ディナー。
大変楽しかった。全員とゆっくり話せなかったのが残念だ。 Gemstoneの人と隣り同士になっていろいろ話した。 やっぱりポートランド近辺に住んでるRandal Schwartz(Schwarzian TransformのRandal)が 今は彼の下で働いててSmalltalkを書いてるんだとか。
もっとも彼は以前もSmalltalk書いてたんだそうで、 知ってる人にとってはそんなにびっくりするようなことではないのかもしれないけど、 私はびっくりした。
日曜日に用事があるためまわりの人たちよりも1日早く出発。
ヒルトンからシャトルで空港まで。14ドル。 MAX(2ドル)に乗った方がよかったかなあ。
ポートランド空港では無線LANが無料で使える。ありがたい。 ポートランドからサンフランシスコ。 サンフランシスコから成田。 空港でゲートを間違えてちょっと焦った。
成田について４時。 メールチェックしてから羽田へ。
羽田は大混雑。 なんでも雪のため北方向の便がそうとう欠航しているらしい。 で、そうこうしているうちに私が乗るはずだった米子便も欠航。 がびーん。
朝イチの便を予約し、ホテルに泊まる。 青物横丁の東横イン。
明日には帰れるか。
また表彰していただいたらしい。 ありたがいことである。
期待されているということだと思うので、 期待に応えられるようにしたいものである。
というわけで対談することになった。
対談というのはプレゼンと違って事前の準備はさほど要らないので 気は楽なのだが、聴衆にとって価値が出るかどうかはかなり運次第である。 まあ、弾さんとならばそんなにハズれることはないんじゃないかなあ。
以前にもCodeGearのデベロッパーキャンプの時にも会ったし、 今月のデブサミでもかなり長い間、話をする機会があったが、 ほんとうにいい人である。
また、Rubyに対するコミット加減もこっちの方が当惑するぐらいである。 たいへんにありがたい。
ところで、デブサミで彼がマイクロソフトの波村さんをつかまえて、 「Andersと働いてるのか。奴は俺の長年の友人だ。昔一緒に働いててな」などと 話しかけていたのが印象的である。
早起きして羽田に。
昨日から札幌便とか全然飛んでないので、空港は大変な人だかりである。 eチケットなので窓口に並ぶ必要があったのだが、 羽田のANAは人間がいる窓口が圧倒的に足りないので、 こういう異状事態が起きると大変な行列になる。
で、行列に並んでいると、私が乗るはずだった米子便が欠航になったとのアナウンスが。
がびーん。
仕方がないので、予約変更。次の便は空席待ちになった。
で、そうなると欲しいのがネットアクセス。 ところが、現在使っているX61はどうにもWEPキーがあるAPへの アクセスができない。
しょうがないのでndiswrapperをアンインストールし、 2.6.24に標準添付されているiwl4965モジュールを使ってみることにする。
いくつかおかしな点はあるが、とりあえずWEPキーを設定してアクセスできるようになった。
おかしいこと。
なんでだろう？
ちょうど私まで空席待ちが乗れたので、 11時の便で米子まで。 雪で欠航ということだったので、 どんなに積もっているのかと思っていたら ぜんぜん雪なんかなくて拍子抜け。
用事が残っていたので、一度教会によってから自宅へ。
思いっきりくたびれた。
で、今日はRubyの15回目の誕生日である。
私が石塚さんと(chat*1経由で)話をしていて、プログラミング言語を作ることと、そのコードネームとしてのRubyが決まったのが1993年の2月24日ということである。 この時点ではまた1行もコードを書いていない。
ソフトウェアの誕生日がいつか、という点において合意は得られていないと思うが、 そもそも物理的な実体がなくコンセプトこそが重要であるソフトウェアにおいては 「作ろうと思った」、「名前が決まった」というのがもっとも重要なイベントであると思うのである。
最初のリリースを誕生日だと見なす人もいるだろうが、 その場合にはRubyの誕生日は1995年12月21日ということになるだろう。
で、誕生日に何をしたか、というと特に何もしなかった。 薄情だろうか。
*1 より正確には我々が作ったマルチユーザtalk、mtalk
時差ぼけか、体がだるくてやる気が出ない。 過去の経験だとこれが5日から1週間続く。
先日のGoogle TechTalkのビデオが公開されている。
で、redditのコメントか見てると「英語へたくそ」というコメントが多くて泣けてくる。 が、英語の勉強するくらいだったらそのぶんコーディングしてたいので、 無視することにする。
文句を言うような奴は聞かなくていい(涙
泣いてやるッ。
それはそうと、鵜飼さんのブログによるとSteve Yeggeが
Who's going to take point on handcuffing him to a massage chair until he signs his offer? -- Steve Yegge
と言ったんだそうだけど、Steve Yeggeが私のようなものとGoogleで一緒に働きたいと 思ってくれるというだけで幸せだ。
働かないけど。
Monkey Patchingとは既存のメソッドを置き換えちゃうテクニックのことだが、 Ruby(特にRails方面)で多用されている。
言語そのものをどんどん拡張できるという意味で非常に強力かつ便利なテクニックだが、 良いことばかりではない。
Monkey Patchingは本質的にグローバルな状態変化であるため、 思わぬ影響がでないという保証はない。 また、複数の場所から同じメソッドに対してMonkey Patchingを行おうとすると 衝突により不整合が発生する可能性もある。
Ruby 2.0ではnamespaceやpackageやmethod combinationでこのような問題に対して なんらかの対処を行おうと考えている。
時差ぼけも抜けきらないうちに 大阪でセミナー。
今回はオープンソースをお題に、
による講演。
夜は田代OSSセンター長から夕食のお誘いもあったのだが、 まっすぐ帰ることにする。
帰りの飛行機で、アメリカに一緒に行った島大の先生に会う。 月曜、火曜と長崎だったという。どんだけタフなんだ。ありえん。
そういう意味では、実は東京は新しい価値を生み出す必然性が乏しい土地なのかもしれない。今までの価値観で物事がすごい勢いで流れている。その流れの中での勝負。
必然性という意味では、今までのやり方では勝てなかった土地にこそチャンスがあるのかもしれない。新しいやりかた、インターネットなどのテクノロジーを駆使しないと勝てない土地。
これがインターネットを活かした新しいサービスが生まれる土地なのかもしれない。
そうなのか。
私の住んでいるあたりは「今までのやり方では勝てない」という点では よそに負けない自信があるが(なんてネガティブな自信)、 ここから「新しいサービス」を誕生させるためには 民間にちょっと危機感が足りないかもしれない。
行政はかなり危機感を持ってて、それがRubyCity MATSUEとかにつながっているわけだが。
SQLiteの開発にリソースが集まるのはいいことだと思う。
ところで、参照先の記事には
SQLiteは、厳密な意味ではオープンソースソフトウェアではない点に注意すべきだ。SQLiteの基本的なソースコードはパブリックドメインの下で公開されているが、これはOpen Source Initiative（OSI）が定めているOpen Source Definitionの技術要件を満たしていない。
とあるのだが、パブリックドメインがOSDを満たさないというのは初耳だ。
朝起きてメールチェックしていると、 今日のミーティングの時間についてのメールを発見した。
今日が楽天の打ち合わせの日であることをすっかり失念していた。 どうやらなんかの加減で手帳にスケジュールを書き込み忘れていたらしい。
大あわてで飛行機の予約をし、朝食後すぐに出発。 無事間に合った。
いやあ、朝のうちに気がついてよかった。 ミーティングが始まってから「まつもとさんどうした？」とか 電話がかかってたらどうしようもないものな。
楽天による電子マネー。事前に購入しておかないといけないのが いまいち使い勝手が悪そうな。
小額決済や寄付などに便利なので 日本でもPayPalくらい電子マネーが普及してくれるといいんだけどな、 と常々思っているんだが、なかなか道は険しそうだ。
もうちょっと使い勝手が良いように思えるイーバンク銀行のメルマネでも さっぱり使われてないものなあ。
楽天キャッシュの方は
というメリットがあるが、普及にどれだけはずみがつくか。
Mac OSXで動作するRubyというだけなら単にコンパイルするだけでよいのだが、 このMacRubyは、YARVをベースに
するという大胆なもの。すげーっ。
これが成功すればRubyは名実ともにOSXの公式スクリプト言語として定着するに違いない。
言語設計者として一番気になるのは、リストの最後にある「Objective-C呼び出しへのマッピング」。 上の例では「foo:bar:」というObjective-Cのメソッドが存在しなければ 通常のfooメソッドの呼び出しになるようになってるそうだ。
将来(2.0?)のキーワード引数に対するヒントになるかもしれない。
言語実装者として気になるのは、世代別GCの実装。 確か明示的なライトバリアが必要なタイプだったと思うんだけど、 これをどうしたかっていうのも興味深い。
っていうか、手元にOSXマシンがなくて試せないってのはどうなのよ。
最近はMacBook安いし、ひとつ手元にあっても、という気もしないでもないのだが、 あのポインティングデバイスが駄目なので*1、 どうにも購買意欲が。
*1 試したがiPod Touchも駄目だった
Monkey PatchingがRubyを破壊するっていうけど、 Rubyを破壊するって言われたものは他にもいーっぱいあるよね、って話。
Ruby、危うし(苦笑
事前に予告していたので、1.9.0-1のリリース準備をする。
とりあえず他の人は盛り上がらないので、 ひとりで細々と失敗するテストを見直す。 まあ、みんなそれぞれ忙しい事情を聞いてしまっているので、 なかなか声をかけづらいのもある。 自業自得っぽい。
が、しばらく放置していた失敗するテストには 直すのにてこずるものも多く、 今日中には終わらないかも。
またリリースは遅れそうだ。
今度からは誰かに音頭取りを任せないとなあ。
笹田くんのインタビュー。
研究と実用の狭間で。
ってか、我々のやってることって研究的には新規性はないんだけど、 でもRubyに組み込まないと世間の人にとってうれしくないんで やることに価値がないわけではないという、 アカデミアにとっては微妙なポジションで。
そこにあって、ちゃんと論文を書いてる笹田くんはたいしたものだと思う。 私は書けなかった。
ま、私の仕事に学位は関係ないんで熱意が足りなかったってのもあるけど。 将来、大学に就職しようと思ったりしたら、後悔するのかなあ。