わりと信じやすい性質なのか、 例年この日は、妻にいいようにだまされている。
「あなた、外は雪よ」
「ウソっ」「ええ、ウソよ」
とか。
が、今年は日曜日なこともあって、平和であった。 別にだますこともだまされることもなく。
やっぱウソはいかんよ、ウソは。
っていうか、私はウソに堪えられない性格で たとえば映画「ミセス・ダウト」のような、 ウソをついて、 それをごまかすためにさらにウソを重ねるとかいうような ストーリーだと、悶絶してしまって、最後まで正視することができないのだ。 どうもバレた時の悲惨さをリアルに想像してしまうようだ。
ロビン・ウィリアムズ好きなんだけどな。 ちょっと下品なところも含めて。
今年とりあげる唯一のエープリルフール・ネタ。
正直、それほど面白いわけではないけど、 ちょっとニヤリとしたので。
でも、まじめな話をすると、正直「オブジェクト指向機能を取り除いたRuby」って 存在できないような気がする。
ただ、
なら見てみたいような気がする。これらは成立不能というわけでもなさそうだし。
互換性はともかく。
今日から本年度のセミナリーが開始。
うちの長女が今年から参加。 起きられるかどうか心配だったけど、 とりあえず問題なし。
今年は教義と聖約と教会歴史。
教える方も大変だ(私だケド)。
「Railsって難しそうだから」というエンジニアがいる一方で、 Rails本を３冊ほど買って試しているうちに「やったらできちゃった」という非エンジニアがいる、という話。
Railsやらなんやらで敷居が下がると、 エンジニアの価値ってどこに残るんだろう、ということになる。 うかうかしてると足元が危ういかも。
表題の通り、JRubyが
しているという話。着実に前進している。
そのうち追い越されちゃったりして。
先日の「What's Wrong With Ruby」に続く第二弾。 今度は反対の立場から。
ま、「いい点もあるよ」という話。 先日のと、これと、一遍にリリースしておけば面倒なことにならないと思うんだけど。 それは予想の範囲外だったのかなあ。
日本ユニシスと日本HPのOSS担当者の対談。 なんだかよくわからない。
特にわからなかったのは、ここ。
伊藤 OSS の有効活用には、技術や知財を形にして、安心感を提供することが大事ですね。
赤井 自社の知財として、OSS をトータルソリューションの中に組み込み、ベストプラクティスを提供していくことも重要でしょう。
えーと、なにをおっしゃってるんでしょう？ 宇宙語？
「安心感」はともかくとして、「技術や知財を形にして」がなにを意味するかは不明瞭だし、 「自社の知財としてOSSを〜組み込み」というのは、 思いっきり誤解される表現だと思う。ジャイアニズムの匂いがする。
オープンソースをビジネスに利用することについては、 むしろ積極賛成派の私だが、少なくとも意味のわかる話をしてほしい。 担当者(「OSSセンター長」と「オープンソース&Linux推進部 推進マネージャ」)の 対談で、こういう「わけのわからない」表現を見るようでは、 逆効果ではないだろうか(元ページはユニシスのPRページ)。
個人投資家は機関投資家の「餌場」としての役割がもっとも期待されている、という話(なのか？)。
ま、情報格差から滅多なことでは対等な土俵には立てないわけで、 うかうか乗り込んでもカモになるだけというのは少し考えればわかるわけだが、 まあ、考えないんだろうなあ。
Rail 1.2は1.1と比較して倍遅いという話が出ていたが、 実際にちゃんとベンチマークを取った結果、 ライブラリが大きくなったぶん、ロードに時間がかかるが、 それ以外はたいして変化していないという結果になった、という話。
AutoLoadでロードの負担を減らすというのはRuby/Tkで効果があったテクニックだが、 Railsではうまくいかないような気もする(結局全部使うから)。
動的言語ワークショップ。 今年はベルリンだっ。
去年はプログラム委員に名前が入っていたが、 本当に名前だけという情けないありさまだった。 今年は迷惑をかけないようにしよう。
７月３１日だとちょっと難しいかなあ。 弟の誕生日だし(関係ないか)。
「LispがCより速い時」。
遺伝的プログラミングではon-the-flyコンパイル(たぶんJITのこと)がある CommonLispの方が速かった。まあ、動的に関数を作れないCだと、一種の言語内インタプリタを作る必要があるから、速いのは当然といえば当然かも。
「Greenspunの第十原則」の一種か。
Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
十分に複雑なCまたはFortranのプログラムは、場当たり的で、仕様が決まってない、バグだらけで遅い、CommonLispの半分の実装を含む
朝から家族で米子の実家へ移動。 両親に子供たちを預けて、妻と米子空港から東京へ。
まず、広尾の神殿により、 その後、ホテルにチェックイン。
ホテルオークラとホテルニューオータニを間違えてしまったのは内緒だ。 どうも、ぼーっとしている。
しばらく休憩した後、新宿へ移動。 買い物と晩ご飯。堪能した。
結婚して１５年、妻が思ったより都会好きであったことは意外であった。 本人によると「新しい街を歩くのが好き」ということだが、 田舎じゃそんな刺激は無いものな。
住むとなるとまた別なのだろうが。
スタックベースの関数型プログラミング言語。
オプショナルな型システム、 名前付き引数、 MapReduceの実装があるというのが、とりあえずの注目点かも。
OSの開発は楽しいだろうと思うよ。 言語の開発もだいたい同じだし。
そして、どちらも理解できない人には決して理解してもらえないものなのだ。
いさぎよく理解してもらうことはあきらめて、 実績をあげてその成果を認めてもらうなり、 「自分の楽しみ」を徹底的に追求なりするしかないような気がする。
ホテルで朝食後、チェックアウト。同ホテルの表彰式会場へ。 めずらしくスーツ姿。
会場について驚いたのは、 私一人、演壇の直前に席が指定されていること。
これはなんの晒し者ですか？
その後、いろいろとあいさつがあった後、 対象受賞者によるプレゼンテーション。 ５分という予定であったが、そうとう早口で話しても6分かかってしまった。
日経BP技術賞とは、 日経BPの記者たちがその年に登場した(or 話題になった)技術を推薦し、 その中から学識経験者が6分野12技術を選んだ上、 さらにその中からひとつを大賞に選ぶというシステムになっている。
6分野は以下の通り。
で、今年は「プログラミング言語Ruby」が情報通信部門で大賞を受賞したということなのだそうだ。
で、この受賞だが、聞くところによると
なのだそうだ。いかに普段から特異な(メインストリームからはずれた)変な活動をしているかがよくわかるような結果だな。
で、プレゼンテーションの内容を始めとして、授賞式の様子は ITproの記事、「【日経BP技術賞】「Rubyが評価されたのは，技術や機能ではなく“感性”」，大賞受賞のまつもと氏語る：ITpro」にまとめられている。
他の技術賞部門賞は以下の通り。
見れば見るほど、私の受賞が変な感じ。
その後、懇親会が開かれた。懇親会の様子は別の記事「【日経BP技術賞】「プログラマの快適さが生産性を向上させる」---Ruby作者まつもとゆきひろ氏：ITpro」に。
松江市の松浦市長も来てくださって、簡単にスピーチしてくださる。 あいかわらず市長は本気である。 お役に立てるとよいのだが。
日経BPは受賞を記念して「日本で生まれ世界が育てた言語 Ruby：ITpro」という特集サイトも開設してくださったそうだ。
その後、妻の希望で原宿へ移動。 原宿はゼータビッツからの分離以来か。当時は本社が原宿だったからな。
私は別にすることも無いのだが、 普段なら絶対に来ないような街の、絶対に見ないような人を見てるのは それなりに楽しかった。
秋葉がサブカルチャーの中心であるというならば、 原宿はまた別のカルチャーの中心であるような気がした。
最近行ってないけど、池袋や中野も面白い発展をしてるとか。 今度見に行こうかなあ。
その後、飛行機で米子へ。 子供たちを拾って、自宅へ帰る。
くたびれた。
ちょうど同じ頃開かれていたYAPC::Asia::2007での弾さんのプレゼン。
これを見て、RubyのM17Nでもせめて
\x{5F3E}
\N{WHILE SMILING FACE}
くらいはできるようにしようと考えた。
子供たちは部活、妻は(昨日までの旅行で)疲労、 ということで私だけ米子に行って総大会土曜の部を聞きに行く。
改装が終わったタバナクルが再奉献されたこととか、 お話の内容とか大変タメになった...と思ったんだけど、 今思い返すと結構忘れてるな。もうちょっとメモを取っておくべきだったか。
まあ、来月になればぜんぶ文章で読めるんだけど。
新番組。 娘が録画しておいたものを見る。
なんと懐かしい。１話の段階ではストーリーは原作に忠実のようだ。 映画は超圧縮ストーリーだったが、テレビシリーズなら ちゃんと話が追えるかも。
長女によると「ベタな設定」だそうだが、確かに
とか、よくあるテーマかもしれない。 が、当時は新鮮だったんだよ。
もちろんその頃でもすでにSFでは使い古されてたテーマだったんだろうけど。 懐かしさと共に今後に期待。
って、もしかして今『地球へ...』ってのは、 もしかしてコアターゲットは私と同世代？
息子は夕べから吐き気を訴えていて、 祝福したらだいぶ回復してはいるのだが、 米子への移動は無理そう。 次女も調子が悪いということで、 世話役の妻、次女、長男は留守番。
長女と末娘だけ連れて米子へ。
昨日に引き続き、すばらしい説教であったが、 子守りに追われたのが残念であった。 末娘がもうちょっと成長してくれると助かるんだがなあ。
とはいえ、今の時期のかわいらしさは今しかないので、 それはそれで惜しい気もする。親ってわがまま。
お昼時には一族そろって、米子の教会の桜の木の下で花見しながら昼食。 なかなか風情があった。
帰ったら、今度は長女が「気持ち悪い」とか言い出すし、 末娘は吐くし、大変だった。
末娘はニコニコと夕食を食べながら突然吐き、 その後、なにごともなかったように食べ続けた。 どういうことよ。
これは家族全員を席巻しそうだな。
学校は始業式。 息子は元気に出かけたが、 長女、次女は初日から欠席。 前途多難である。
「マイクロソフトは死んだ」。
まあ、世界最大のソフトウェア会社は簡単なことで潰れたりしないし、 それはPaulも認識しているだろう。このエッセイの中で言及されてるIBMも 潰れてはいないし。だから、 より正確に言えば「マイクロソフトはもう恐くない」。
しばらく前に丸山先生レクチャーシリーズに顔出した時に 印象的だったことがある。 マイクロソフトの人が彼らのガジェットについて解説していて、 他のデスクトップガジェット(OSXのとか、Yahooのとか)との違いについて 語った時の言葉。
それはインストールベースです。 Vistaにはすべてガジェット機能がインストールされます。 この数については他のガジェットには真似できません。
正確な言葉ではないけど、こんな感じ。
彼は数の論理についてよく理解していて、 限りなく「マイクロソフト的」だと思った。 「ブラウザの外」ではまだこの論理は有効である。
正式にページが公開になった。楽しみなことである。
Ruby on Railsを使ったからといって、 それは定型的なコストが下がるだけであって 作業の本質が減るわけではない。 必要以上の期待(幻想)を抱いてしまうと、「炎上」することになる、という話。
ま、当たり前といえば当たり前だけど、 Rubyについても、Railsについても幻想ではなく 実物大のメリットを享受していただければと思う。
JavaScriptはスコープの制御が関数レベルでしかできないから、 グローバル変数を導入しないためには「ちょっとしたテクニック」が必要、という話。
ま、もっともな話ではあるのだが、 こんな簡単なことが簡単にできない言語は、少なくともユーザに優しい言語ではないと思う。
レコード(CD)業界がいかに「愚かな」選択を積み重ねてきたかということと、 日本では着うたフルのおかげでDRMフリー化は遠そう、という話。
いずれにしてもなんらかのDRMが導入された時点で 我々「Linuxユーザは切り捨て」と同義だよね。 少数派を切り捨てるのはビジネスとしては当然の選択だが、 切り捨てられる方は穏やかではない。
私は、諸君の中の少数派に呼びかけている！
少数派の諸君！今こそ団結し、立ち上がらなければならない！
奴ら多数派はやりたい放題だ！
我々少数派が、いよいよもって生きにくい 世の中が作られようとしている！私は、この国の、少数派に対する迫害にもう我慢ならない！
少数派の諸君！多数派を説得することなど出来ない！
奴ら多数派は、我々少数派の声に耳を傾けることはない！
自由は無料では手に入らないということか。
「1日4時間」でもすごいけど、この人の場合には「1週間に4時間」。おそるべし。
要するにパレートの法則(８０:２０則)を徹底して、効果の高い20%に集中したら それくらいでも済んだということ。
実際に自分の仕事から無駄をなくしたら、 1週間に4時間は極端だとしても、かなり実働時間は減らせるかもしれない。
自分の生活に対するハックを怠らない私も、 日々の精進を積み重ねた結果、 最近ではコーディング時間が1週間に4時間を切るようになった。 その他の時間は、ブログを読んだり、メールを書いたり、 原稿を書いたり、原稿を書いたりしている。
ちっとも生活が楽になった気がしない。 もっとコードが書きたい。
朝、セミナリーから帰ったら具合が悪い。 同じ頃、妻も吐いたという。
で、この日は妻と二人で一日中寝ていた。 夫婦揃ってこれほど具合が悪いのは１５年の結婚生活の中で初めてじゃなかろうか。 末娘は元気なので、交代で少しずつ面倒を見たり。
とにかくしんどかった。
夕食はお姉ちゃんたちが昨日の残り物をベースに作ってくれた。 子供の成長がこれほどうれしかったことはない。 ありがとう。
次世代DVDのプロテクトを維持するためのメーカーの努力、の話。
メーカーがいくら頑張っても、 そんなに頻繁にキーを変更できるわけはないのだから、 勝ち目のない争いのような気がする。
っていうか、あんまりDRMで頑張ってもらうと使いにくくなってしょうがないんだけど。
不毛な争いはやめて、 どうにか、使いにくくない線で折り合いがつけられないものか。
Pythonによるエンコーディングデテクタ。なんでデテクタなのに「kf(kanji filter)」なんだろう？
Universalchardetに比較すると 日本で使われるエンコーディングしかサポートしていないという難点はあるが、 ぜんぶPythonで書いてあるので遊びやすいというのはある。
「Erlangの人」Joe Armstrongによる、「なぜOOは良くないか」。
2と3はちょっと誤解っぽいけど、残りは 関数型プログラミングの視点からはもっともだと思う(特に4)。 だけど、世の中にはそれに耐えられない人もいるのよ。
現実世界に「状態」があるのに、プログラミング言語がそれを表現できない (ということは、間接的に表現しなければならない)というのは、 私の脳内モデルとプログラムの距離が遠くなって大変つらい。
現実世界から副作用のない関数モデルへのマップが脳内でできる(関数脳)状態の人には 関数型言語が最適なのだと思う。 問題はどうやってそれを構築するか、だれも言語化していないことだ。 「習うより慣れろ」とかいう精神論しか聞かない。 それはあまりにスパルタな。
それとも私が知らないだけ？
JRubyの紹介。JRubyを介してJavaな人の視野にもじわじわとRubyが進出してきているようだ。
たとえ、仕事ではJavaしか使わないにしても、 Rubyを知っておくことは無駄ではないと思うよ、実際。
ただ、仕事でJavaを使うのが苦痛になるという副作用があるかもしれないから、 それには注意。
Bluegene/LのノードでRuby 1.8が動いた、という話。
考えてみれば、全体としては世界最速のスーパーコンピュータだとはいえ、 各ノードはLinuxマシンなわけで、別に珍しいことではないかも。
ただ、Bluegene/Lのノードはスレッドに対応していないので、 YARVは動かないらしい。そういうものなのか。
「猛々しいプログラマ」とは、猪突猛進でどんどん進めていくタイプのプログラマだそうだ。 協調性もなさそう。
小学3年生のその子供は，プログラムを作り始めると，人の言うことなど聞かない。ロボットの動きだけをたよりにどんどんプログラムを作成していく。彼はそれを「猛々しいプログラマである」と表現した。自分が作ったプログラムを人に説明することはできないが，人に指示されるよりも自分の理解を基にプログラミングを進めていく姿勢に対して，ベストプログラミング賞を贈ったという。
猛々しいプログラマ──やや閉塞感のある日本のソフトウエア産業界にブレークスルーをもたらすとすれば，こうした人材像ではないだろうか。
そうかもしれない。日本の職業プログラマはお行儀が良すぎるのかもしれない。 ま、ほとんどのソフトウェア開発はチームワークだから、必然でもあるのだけど。
が、驚いたのはその後。
例えば，まつもとゆきひろ氏は，職業としてはプロのソフト開発者である。しかし，Rubyの開発に限っては，完全にホビイストの立場だったのではないだろうか。彼がおもしろいと思いながらひたすら作り上げたRubyは，世界中で利用される優れたプログラミング言語となった。
まさか、私が言及されるとは思わなかったな。 「猛々しい」は私の人格を的確に表現している形容詞だとは思わないけど、 「好きなことをしている」、「協調性がない」という点は当たってるかな。
今年もGoogle Summer of Codeの採択プロジェクトが決定した。 昨年同様RubyCentralもホストとして参加する。
個人的に興味があるのは
くらいかな。
C# 3.0との比較でHaskellを学ぶ、という話。
というか、これだけ比較が成立するのは、 C# 3.0がいかに関数型言語の「マネ」をしているか、 ということでもある。そして、それはとても良いことである。
「PHPはダメだ」、という話。
本エントリでは、まずPHPの良い点から紹介している。
しかし、良いところはそこまで。
私にとって2や5は少々意外だった。 PHPの人気や実績から考えたら、この辺は当然クリアしてると期待するじゃない？
とはいえ、実際に「喜んで」PHPを使っている人はそれなりにいるわけで(「しかたなく」使っている人も大勢知ってるけど)、そういう人たちはまた別の理由や動機があるのだろうか。 それとも「現状に満足しちゃってる」とか、「新しい言語を学ぶくらいだったら、非効率な方がマシ」ということなんだろうか。時として「知らないこと」は強力な動機となるわけで。
最後にJonasは「残されたPHPを使う動機」として以下のものをあげている。
で、彼の結論は「For me, PHP is now an unacceptable solution to all but the simplest problems」なのだそうだ。PHPを使ってない私がなにを言ってもまったく説得力がないけれど、 この人はそれなりにPHPの経験を積んだ上での発言のように思える。
あなたの結論はどうだろうか。
FasterCSVよりもさらに高速なCSVパーザ。 すばらしい。いっそ標準添付のものを置き換えちゃうか。
いつの間にかLightCSVに改名されていた。ダウンロードはこちら。
私の日経BP技術賞大賞受賞記念ということで、プレゼンテーション。
今回はRubyを技術賞に推薦してくださったITProの高橋さんにも 松江に来ていただいて、技術賞とはなにかとか、 受賞の意味とかについても発表していただく。
しかし、ありがたいことだ。
で、私の発表の内容は、授賞式のプレゼンテーションとほぼ同じで、
とか言うような話。授賞式と違って５分という縛りがなかったので、 もうちょっと言葉多くして３０分くらい。 後、質疑応答。松江らしく(？)おとなしいものであった。 もっと質問しないともったいないと思うんだけどなあ。 それでも、オープンソースの基本的なことから、 PHPとの比較など技術系、非技術系とりまぜた質問が出る(指名したり、ちょっとむりやり感はあったけど)
その後、懇親会。
年齢がひとつ増えた。めでたい...ことではないか、人生折り返し地点を過ぎてれば。
娘が私のためにシュークリームを焼いてくれた。 膨らみが足りず見てくれは、お店のものには敵わないかもしれないけど、 味と愛情は負けてない、と思うよ。
昼食はモスバーガーで新しくなったというモスバーガーに挑戦。 しかし、味の違いがわかるほどモスバーガーを食べつけていなかったりする。 おいしかったけど。
「静的vs動的」の戦いにはほぼ決着が見えてきて、RubyやPythonの人気が上がり、JavaやPHPが落ち目になっているように「見える」。 だとすると、「次の戦い」のテーマはなんだろうか、という話。
彼の意見はこんな感じ。
どれも興味深い。いくつかは「将来のRuby」にも取り込みたいと考えている。
基礎知識としてプログラミング言語を学ぶなら、なにを選ぶか、という話。
ここで挙げられているのは以下のもの。
無難なリストではある。
James Clark、JSONについて語る。
ネームスペースがない、という指摘はわかるようなわからないような。 確かに表現すべきデータ構造が複雑になった時に ネームスペースのようなものがほしいことは、もしかしたらあるのかもしれないけど、 ほとんどの場合には「配列、マップ(オブジェクト)、文字列、数値」で 表現可能なのではないだろうか。
それを越える場合には、確かにJSONではカバーしきれないだろうが、 ごくまれな特殊なケースのために巨大な道具を持ち込むのは間違っている、と思う。 もともとXMLも、巨大すぎるSGMLや一貫性のないHTMLへの対案として誕生したはずなのに、 今や(well-formedな一貫性は維持されてると思うけど)、 揶揄の対象になるくらい巨大になってしまったような気がする。
JSONについては、外から受け取ったデータを 安易にevalに渡してしまうようなケースの方が心配。
あまり目立たないがJRubyの立役者であるOla Biniが大学から ThoughtWorks(Martin Fowlerがいるところ)に移って、 フルタイムのJRuby開発者になる、という話。
すげー。
っていうか、 本家Ruby開発者は(私以外は)なかなかフルタイムという話はないのにな。 笹田くんは結構近いけど。 それを思うとやっぱJavaの威光はすごいな。
アスタリクスの中島社長のインタビュー。
「Google恐れるに足らず」というのは強気な発言であるが、 日本ベースであるがゆえにGoogleにはできないことはあるだろう。 エンタープライズRubyの先駆けとしてぜひ成功していただきたい。
NaClも応援している。実際に一部開発してるし。
「Twitterの中の人」Alex Payneがインタビューで
ぼくたちは世界最大のRailsユーザーだと思うけど(毎秒11,000リクエスト受けたことがある)、Railsはスケーラビリティが課題だよね。Railsは同時に複数のDBと話すことができないし(超訳)
と、発言したのに対して、DHHが
RubyもRailsもオープンソースだし、簡単に手を入れられるんだから 誰かが自分の問題を解決してくれないか、口をあけて待ってるんじゃなくて 自分で解決して世界に貢献したらいいのに
と発言。
それを受けて、解決手段であるMagic Multi-Connections をNic Williamsがリリースという流れ。
どこに突っ込めばよいのかわからない、この流れ。
DHHの挑発的な応答もさることながら、 それに対してわずか75行のプラグインで対応できてしまうNic Williamsのセンスや そもそもそれを可能にしたRailsというアーキテクチャ、 またその背後にあるRubyのパワーなど、考えるべきことはいろいろある。
「我慢して頑張る」を嫌う「新人類」型新入社員について。
かくいう私の世代は世に言う「新人類」という言葉で最初に形容された世代になるのだが、 この「我慢して頑張る」を嫌う感覚はよく分かる。 会社が一方的に押しつける都合を嫌い、「頑張る」必然性を見いださない。
っていうか、会社と従業員との関係は常にWin-Winであることを目指すべきで、 従業員が一方的に我慢する構造というのは間違っている。 この業界、徹夜しても仕事を完遂する「すばらしい」人は多いのだが、 そのすばらしい働きは、ほとんどの場合、さほど評価されない。 私にはその「報われない」責任感がよくわからない。なんで我慢できるんだろう。
あなたが(自らの身を削ってまで完遂する)すばらしい火消しでも、 たぶん、あなたは出世しない。あなたのキャリアはいつもトラブルの渦中にあるのだから。 経営者からは、あなたはトラブルとワンセットでしか見られない。
プロジェクトが火を噴いているのは、たぶん、あなたのせいではない。 でも、責任をとって徹夜するのはあなただ。 「遅れてすみません」と頭を下げるのはあなただ。
でも、会社はたぶんあなたに報いてくれない。 責任者はあなたに感謝はするだろうけど、それ以上ではない。
それでもなぜ頑張るのか。 一度や二度の突発的な事態なら仕方がないかもしれない。 でも、これが恒常的になるなら、あなたは転職を考えた方がよい、と思う。
「我慢して」も「頑張っても」、将来報われるなんてことは期待できないと思う。 今三十代より下の人にとっては「将来のおいしいパイ」なんてのは、 上の世代がぜんぶ食い散らかした後だ。
「怠けてもよい」とは言わないが、楽しんで仕事すること、充実した仕事をすること、 そして、会社とWin-Winの関係を築くことを、もうちょっと真剣に考えてもよいと思う。
長男、誕生日。10歳。ケーキを食べる。
Luaにマクロを加える試み。文法がS式でない言語へのマクロという点で 非常に興味深い。
同じinfix文法を持つ言語でも、 Dylanのマクロよりは ずっとわかりやすいが 美しくはない。
RubyでできたLispのコンパイラ。
まず、LispをLuaのものに良く似たバイトコードに変換し、 さらにそれをpure Rubyのコードに変換するというコンパイラ。
高橋会長のプレゼンテーション(高橋メソッド)。 ウケている。
Appleの営業の人による「あなたがMacを買わない10の理由」のパロディなんだが、なんともおかしい。 特に言語がAdaであるところが。
でも、Adaのことを全然知らないとこのおかしさは伝わらないだろうなあ。
Termiteっていうのは、要するにScheme(Gambit)に Erlangの並列モデルを組み込んだもの。リンク先の論文には 結構性能が出ているような話も見える。
Rubyでもそういうのをやったらよいような気がする。
Steve Yeggeによる「次の言語」の条件。
私は賛同しないけど(特に最初の二つ)。
コメントではDylanやJavaScript、DやC#3を押す人がいた。 でも、これらも「次」って感じじゃないだろう。
じゃ、私は「次」の言語はどうなるか、と考えているか、という話。
こうやって、言語の話題をあちこちでチェックしていると 次世代のプログラミング言語についての傾向がわかってくる。
というわけで、 次世代の言語を今味わいたい人はErlangもいいかも。 今はTIOBE Index ５０位以下だが、今年のLanguage of the Yearになるかも。
OOPの「欠点」。
本文だけだとよくわからないけど、筆者によるコメント欄でのサマリが面白い。
オブジェクト指向は複雑なソフトウェアを取り扱えるが故に、 ソフトウェアの複雑化を招くというのは(その主張に同意するかどうかはともかく)、 新しい視点であった。
確かにWindowsの「なんでもかんでも一体化した設計」は、あまりうれしくない気もする。 それが本当にOOPのせいかどうかはわからないけど。
最近、「CommonLispはLisp-2で、SchemeはLisp-1である」という文章を読んだが、 恥ずかしながらLisp-1とかLisp-2ってなんのことだかわからない。 Lisp 1.5なら知ってるんだけど。
ので、調べてみた。
で、その結果、名前空間がひとつ(関数と変数に区別がない)のがLisp-1で、 区別があるのがLisp-2であるということだそうだ。なるほど。
だとすると、PythonやJavaScriptはLisp-1で、RubyはLisp-2だな。
スクリプト言語に欠けているもの、という話。
まあ、最後のものはともかく(Javaよりも開発者が少ないという意味らしい)、 残りについては自覚はしている。次第に改善されるんじゃないかな。
Ruby 2.0ではぜひAST(Abstract Syntax Tree)が欲しい、という話。
一度公開しちゃうと変更できなくなって面倒だから、 という非常に開発者の都合で公開していないんだが、 やっぱりAST機能欲しいんかねえ。
いっそ、RubyのソースコードからS式を吐くフロントエンドを作るというのはどうだろう。 で、S式からYARVバイトコードを作るとか、Gaucheに喰わせるとか。
その場合、Rubyってのは本当にLispの一種になっちゃうね。 なんとなく先祖帰りな雰囲気。
「毎秒、11,000アクセスというのはすごいけど、それDBアクセスいらなくね？」という話。
確かに毎秒11,000回DBにアクセスすると大変なことになりそうだけど、 Twitterの性質をよく考えてみると、そもそもDBに格納する必要のない情報ではないだろうかと。 ActiveRecordのおかげでDBアクセスが簡単になって、 DBを単なるストレージのように扱えるが、本当はSQLデータベースに向いてない使い方も されているんではないだろうか、という指摘。
あと、毎秒11,000アクセスってのは純粋にものすごい数で、 それってAPの設計の見直しでもうちょっと下げられるような気もする。
「なぜRailsはRubyでしか可能にならなかったのか」という話。 TurboGearとかDjangoの人とかは「Pythonでもできたぞ」とか言いそうだけど。
それはRubyismのおかげだそうで、で、「Rubyismとはなにか」ということは、 『Rubyisms in Rails (Digital Short Cut) - $9.99』を読むとわかるんだそうだ。
そうかぁ。 $9.99かぁ。
Rubyのメタプログラミング機能を使ってプロパティやプラガブルタイプを実現する、 という話。
ところで、例題に
property :speed {|v| v >= 0 && vn< 300 }
というコードがあるが、これはSyntax Errorになる。 これはRubyのパーザーが「:speed {|v| v >= 0 && vn< 300 }」をメソッド呼び出しと 解釈しようとするからだが、数値、文字列、配列、シンボルなど 識別子以外のものの後ろのブレースの優先度が高すぎるのが原因だ。
ということで、1.9の文法を少々いじって、文法エラーでなくすことにした。
先日の挑発的なエントリは、ざっくりまとめると
ということであった。
しかし、その中で安易に「転職を考えた方がよい」と 書いたのは間違いであった。なぜならば、 会社とWin-Win関係が構築できていない場合、 その原因の大半はあなたの側にあり、 それを解消しない限り、 転職しても同じことの繰り返しになる可能性が高いからだ。
まず、最初にWin-Win関係とはなにか、についてまとめておこう。
スティーブン・コヴィーの『4906638066』によれば、 利害関係のある二者間での関係は、
の三通りがある。当然Win-Win関係が理想だが、現実にはなかなかそうもいかない。 しばしば、Win-Lose関係や、Lose-Lose関係に陥ってしまう。
経営者とプログラマの関係は、 仕事をしてもらって給料を払うという観点からは双方が得をする Win-Win関係と捉えることもできるが、 仕事と報酬がバランスしていない場合には、 簡単にWin-Lose関係になってしまう。
ここで重要なのは一方がWinしているかどうかという基準は 多分に主観的であるということである。 つまり、給料が安くても仕事内容が充実しているために満足している場合もあり、 逆に給料が高くても精神的なストレスなどのため仕事に不満があるケースも珍しくない。
このことを考えると、あなたが仕事上、正しく扱われていないという不満を持っていても、 それは必ずしも上司があなたから搾取しようと考えているわけではない。 彼らは、おそらく以下のいずれかである。
満足が主観的なものである以上、口を開かないで理解してもらえることは まったく期待できない。
この状態で不満を内に持ちつづけることは非常に生産的ではない。 もちろん、予算が無限にあるわけではない以上、 報酬など待遇にも一定の限度があるわけだが、 少なくとも交渉する余地はあるはずだ。 コミュニケーションは重要だ。
あなたの不満は伝わっているだろうか。 あるいは上司はそもそも聞く耳がないのだろうか。
十分なコミュニケーションを行っても、なおなんらかの事情で 妥協する余地が見いだせない場合には、はじめて転職が有効な選択肢として登場するだろう。 いきなり辞めるのでは、それこそLose-Loseの関係である。
いつのまにそんな話が。
いや、IT関連企業の誘致のために家賃補助というのは、 過去にも似たようなことをしているわけだし(たとえば松江市には電気代補助制度がある)、 そんなに珍しいわけではないのだけれど、 「まつもとと交流」なんてのが「魅力」として登場するというのは 予想の範囲を越えている。
まあ、みなさまの「地域資源」ですから、よしなに活用してくださいませ。
「Common Lispはいい言語だけど、ダメなところもあるよね」という話。
具体的には
とか。些細なことだといえば、その通りだが、 それが気になるくらい他の部分が良いといえば、前向きだろうか。
角谷さんから献本していただいた。
これは良い本だ。おおむね以下のような本だと言えよう。
だから、もっとも重要な点は「Rubyについて」ではない。 あらゆる新しい技術に応用可能だ。
個人的には、私が趣味としてはじめたRubyについて こんなに真面目に「仕事として使う」ことを考えてくれる人がいる ということだけで、胸が一杯になった。
あと、角谷さんが正誤表を含むサポートページを開設している。
島大の野田先生が中心になってやってる講座。 ４月からもう始まっているが、ITproで報道された。
私も６月末に一回教えることになっている。 これの事務手続きが異様に面倒だったが、それも片づいたし。 いちおう、非常勤講師という扱いになるらしい。 また肩書きが増えた。
肩書きで思い出した。
私の肩書きが４月から「(株)ネットワーク応用通信研究所 フェロー」になっていたのだった。 今までの「特別研究員」とどこが違うのかというと謎なんだが。 辞書を引くと「Fellow」とは「特別研究員」のことであるそうだし。
どうも、Rubyが広まってビジネスの中心が移動するのにともなって、 私にインパクトのある肩書きをつけたかったという社内事情があったようだ。
まあ、いいや。肩書きで仕事するわけではないし。 名刺を作り直した以外には別に私自身には変化はない。
オープンソースプロジェクトをうまく運営するための10のルール。
必ずしも全部に賛成するわけではないが、 人間系が重要である点には同意する。
Rubyのxmlrpcライブラリにはセキュリティ上の問題があるのではないか、という指摘。
要するに任意のメソッドが呼べちゃうよね、ということなんだが、 確かに呼べるメソッドに制約を与えないとまずいこともありそうだなあ。 xmlrpcには詳しくないんだけど、制限できるんだっけ。
あとdRubyではどうしてるんだろう。
聖餐会では「什分の一」を中心に経済的なこと。 金銭にまつわる聖句は思ったよりも多いということなどを含めて。
日曜学校原則クラスは「選ぶ自由」について。 我々の生得権である「選ぶ自由」と、その目的、効果、活かし方。 私が教師だったが、むしろ大変為になる話を聞かせてもらった。 子育てとか。
Second Annual Silicon Valley Ruby Conferenceでは、 Rubyプログラマへのリクルーティングが盛んであった、という話。
日本でもそういう傾向は見えつつあるが、 まだ、「Rubyプログラマ優遇」とか「高給保証」とか、そこまでは届いていない。
つか、そういうところまで持っていきたいものだ。 待遇改善には原資が必要である。
DATE 2007カンファレンス(EDA関連の最大のカンファレンス、EDAってなに？)で感じたこと。
システムの規模が大きくなるにつれ、挙動と性質が変化しつつあるということだと思う。 賛成する。
「Pat Eylerのブログコンテスト」、４月のテーマは「未来のRuby」。
What Changes would make Ruby a better language without making it into something that isn't Ruby?"
Rubyを「Ruby以外のもの」にすることなく、Rubyを良くするアイディアについて。
最優秀の人にはApressから好きな書籍をもらえる。
気がついたのが遅かったので(もう月末までわずかしかない)現時点でも結構集まっている。
中には明らかにRubyらしさを失うものも(optinal static typingとか)あるが、 耳を傾けるべきものも多い。が、interpreter lockなしのnative threadingとか、 気持ちはわかるが、実装は無理なんじゃないかと。
Gambit-Cのネームスペースについて。
(namespace ("f#" foo) ("b#" bar baz))
と宣言しておくと、そこから、fooはf#fooに、barはb#barになるので、 ライブラリのロード前にnamespace宣言しておく、というもの。
簡単で、ある程度効果的なのは認めるけど、なんか違和感がある。
Smalltalkの新しいオブジェクトシステム。 Squeakの「フォーク」だから「スプーン」という名前付け。うーむ。
クラスのアンロードができるため、とても小さなメモリイメージを作ることができる のが特徴だとか。実際、最少のイメージは1,337バイトだとか。小さい。
「なぜLispは違うのか」。
CやJavaの観点からLispを見ているんだと思う。 「悪い」と言ってるわけでなく、「違う」と言ってるところが重要なんだろうな。
しかし、これらの指摘の一部は実は動的言語でも共通なわけで、 それが別に問題になってないように見受けられることを考えると これらの違いの多くはさほど問題ではないということだと思う。
とすると、...やっぱり括弧か。
京セラが極端な違いはないのにやっぱり強い、そのことは素晴らしい、という話。
理想的な態度だ。 細部の細かな使い勝手の蓄積によって全体的な強さが構築できるということなのだろう。
Rubyもどこが良いのか言語化できないのに強いというのと 似た性質である....のだといいな。
東京へ移動。今回はいくつかの用事を果たすためだが、 その一つがダイビルでの笹田、中田、まつもとのミーティング。
未踏としての結果を出すためにもロードマップを作る、 というテーマなんだが、普段からロードマップとは無縁の生活をしてるので すぐに脱線しちゃう。
なんだかんだといって決めたのがリンク先のもの。主要な部分は
といった感じ。
うちが提供するトレーニングプログラムのレパートリーが増えました、という話。
それなりに好評のようでありがたい。 売り上げとしてはそんなに多くはないのだが、 これまでの開催でも結構「次につながった」ケースもあり、 無視できない。
教育重要。
Scheme上にErlangの並列実行モデルを実装するTermiteの紹介。
論文だけだとわかりにくいところが実際のコードで見ると 把握しすい。 明示的にforkしているところはちょっと抽象度が低いけど、 「仕組みが見える」と考えると、それはそれで良いのかもしれない。
なんともヘンな言語Enchiladaの紹介。
あらゆるものがImmutableな関数型言語であるEnchiladaは 分散や並列を意識して設計されている。 データ型はリストしかなく(！)、数値などもリストで表現する。 つまり、数は空の式n個を含む配列で表現する(！！)。
Lispは単なる括弧(f x)が
文脈によって決定されるのがつらい、という話。
ま、そういう傾向はある。S式の解釈がプログラマブルであるところが、 Lispの最大の利点であるのだが、最大の欠点でもあるということか。
Rubyに満足できずにPythonに移行したという話。残念。
で３ストライクアウトだそうだ。うーむ。
その他にも「YARVが継続とグリーンスレッドをあきらめて、GCモデルは維持する」という判断に反対なのだそうだ。これは参考にしたい。が、現在のグリーンスレッドにはそれほどの価値はないと思うし、GCモデルによる問題はそれほど大きくないとは思う。継続は確かに痛いけど。
今年も実行委員やります。
変な人をうまく伸ばす、という話。
ま、「真のプログラマ」とか「ハッカー」とかいう人種は おおむね「変人」なのでそれをうまく使えるかどうかは この業界での差別化のために重要なのかもしれない。
とはいえ、変人ばかりでもなあ。
『日経ソフトウェア』のご厚意で結城浩さんと対談。
なんか、話があっちに行ったりこっちに行ったりしたけど、 まとめる記者の人は大変だよなあ。
個人的にはとても楽しかった。 あと、結城さんはもっと線が細い人だと勝手に思いこんでた。 実際、私よりはやせてたけど。
４月のブログコンテストのエントリを勝手に批評するシリーズ(その1)
要するにPerlみたいにメソッド定義がどこにあっても良いようにしてくれ、 という話。
気持ちはわからないでもないが、欠点がある。
メリットよりはデメリットの方が多いんじゃないかな。
なお、余談だが、Rubyのごくごく初期のバージョンは def文でコンパイル時にメソッド定義していたので、 ここでの提案は実現されていた。が、結局今の実行モデルに直しちゃったんだよね。
４月のブログコンテストのエントリを勝手に批評するシリーズ(その2)
このエントリで提案するのは、オプショナルスタティックタイピング。
def my_method(Integer param) puts "Well, hello!" end
で、
def my_method(param) do_something if param.is_a?(String) end
の代わりをするというもの。 自分でも似たようなアイディアについて発言したことがあるので、 気持ちはわかるが、不採用。
まず、元々のis_a?を使ったスタイルそのものがDuckTyping的見地から とても悪いスタイルである「is_a関係でのチェック」になっており、 それを推奨する言語機能を追加することはありえない。 DuckTypingを捨てたらRubyの良い点(悪い点でもあるが)を捨てることになり、 言語の性質を変えてしまう。
なんらかのタイプチェックを追加するならば、 メソッドの保有関係によって行うべきだが、 method_missingを使っているものは単純なrespond_to?を使えないことなども考えると、 これも一筋縄では行きそうにもない。
結局、「Rubyのまま」という制約の下では、 なにもチェックを行わない単純なDuckTypingが最適という結論になりそうだ。
では、Rubyではないまったく新しい(動的型)言語で オプショナルな型チェックを追加するとしたらどのようにするべきか考えてみよう。
「Elvisは生きていた」ならぬ「arcは生きていた」。
アメリカではElvis Presleyが死んだことを認めず、 「いや、実は死んでない」とか、「実は宇宙に帰ったのだ」とか、 「ロッキー山中で目撃した」とか、よくわからない噂が流れることがあるのだそうだ。
本当か。
で、Elvisとは関係なく、 あんまり実物が出てこないものだから、きっと死んだものだと思われていた Paul Grahamのarcだが、どうやら生きていて、Y Combinator内部では実際に使われている らしい。しかも、「cons量を削減して2,3倍の高速化を実現」だそうだ。
「consを減らしたくらいで」と思わないでもないが、arcはそれ自身がCommonLispで書かれているそうなので、コンパイラとランタイム合わせたcons量は馬鹿にならないのかもしれない。
_whyによるRuby(とプログラミング？)の入門ツール。
Windows版しかないのでないので、試せなかった。 Webを見る限り、それなりに評判は良いみたい。
誰か試してみない？
評価記事も出ている。
４月のブログコンテストのエントリを勝手に批評するシリーズ(その3)。
「良い補完付きのIDEが欲しい」というもの。言語そのものとは直接関係ない。
IDEについては、NetBeansが頑張っていることは知られているわけだが、 Eclipse系でも
と結構な動きが出ている。Rubyのプレゼンスが上がるにつれ、 もっと良いものが登場して来るんじゃないかな。
４月のブログコンテストのエントリを勝手に批評するシリーズ(その4)。
現在のブロックコメント(「=begin」から「=end」まで)に変わる新しいものを導入しよう、というもの。 提案されているのは「#*」から「*#」。
個人的にはブロックコメントの必要性はあまり感じていない。 ツール(たとえばEmacsのruby-modeでのruby-encomment-region)で 簡単に対応できるからだ。
たとえ導入するにしても記法はよく考える必要がある。 少なくとも「#*」では既存のコメントに重複するものがありそうだ。
４月のブログコンテストのエントリを勝手に批評するシリーズ(その5)。
ruby-talkの常連djbergによるもの。たくさんある。
Maybe
いちいちコメントつけるだけでも疲れちゃいそうだけど、とりあえず、 1.9で(ある程度)やるものは以下の通り。
曖昧すぎて何ともいえないが、(2.0以降)検討してみたいのは以下の通り。
考えないといけないのはこれ。
もうちょっと良いissue trackingが必要だ。
赤井さんは同郷で(学校は違うけど)、高校時代に個人的に面識もある先輩なので こんな下らないことで辞任というのは残念で仕方がない。
Ruby VMインタビュー・エピソードIII。 Multi-VMのこととか。
Ola Biniに続いて、XRubyの開発者Ye ZhengもThoughtWorksに入社したという話題。
これってすごいことだと思うよ。 で、このままだとXRubyとJRuby周辺で協調と積極的な開発が進んで、 オリジナルRubyが置いていかれそうで、ちょっと危機感を感じたりして。 いや、1.9ももちろんそれなりに頑張っているんだけど。
Haskellでイベントモデルとスレッドモデルを融合した 新しい並列実行モデルを実装したという話。 Linux上のI/OベンチマークでNTPLよりも高速だったそうだ。 ふむ。
まだ論文は読んでない。
「Rubyな生き方について」。 4/16から公開されていたが紹介するのを忘れていた。
改めて読み返してみると、私は変なキャリアを生きてるよなあ。 ただ、「自分の環境をデザインする」という考え方は 誰にも応用できる発想だと思う。
Erlangの紹介。
＠ITみたいなメジャーなサイトでErlangが紹介される日が来るとは。 しかも、私のエントリもリンクされてるし。
Erlangのやり方に時代がやっと追いついてきた、ということだと思う。 もっとも純粋に言語としてみた時のErlangは少々とっつきにくい。 記法にPrologの影響が強すぎるのかもしれない。 あと、エラーメッセージがぜんぜん直感的でない。
もっとも、最大のとっつきにくさは私の関数型言語への苦手意識という 非常に個人的なものなのかもしれない。
達人プログラマーDave Thomasによる最初のErlangプログラム。 これくらいなら別に難しくもなんともないんだけどねえ。
４月のブログコンテストのエントリを勝手に批評するシリーズ(その6)。 最後はJRubyのCharles Nutterのもの。
実際にRuby処理系を実装しているだけあって具体的。
Threading
Thread#kill, Thread#raise, Thread#criticalをなくしたい。
Thread#criticalをなくすのは規定路線。前二者はJavaのスレッドでは 提供されていない機能だからCharlesがなくしたいというのはもっともである。 これらはいずれもより抽象度が高い機能(timeoutとか)を実装するための道具 なので、それらが別の形で提供されるなら(段階的に)取り除いてもかまわない
ObjectSpace
なくしたい(特にeach_objectとか_id2refとかだと思う)。
_id2refについてはThread同様、上位機能(weakrefとか)が実装できれば 問題なし。そのために「_」で始まる名前にしてるんだし。
残りはメソッドのうち、garbage_collectはGCをスタートするだけだから問題ないはず。 each_objectは悩ましいところだが、デバッグ用のオプションを必要として普段は動かないとかは 許容されるかもしれない。こういうのが必要なのはどうせハックだし。 後はfinalizer関係だが、これらはなくすわけにはいかないと思う。
$SAFE and tainting
Charlesの意見は「これらはいらない」というもののようだ。 それなりに便利なのに。
が、$SAFE=4のSandboxは_whyのSandboxのようなもので 実現すべきであるという意見はもっともだと思う。 $SAFE=1だけ残すというのが良いのかもしれない(2.0以降)。
「Javaのsecurity modelにマップすべきだ」という主張は 私自身の知識が足りなくてイメージできなかった。 個人的にはJavaのsecurity modelには「繁雑」という印象しかないんだけど。
Direction
非技術的なのであえて具体的にはコメントしない。 もっともなことだとは思う。
教会のトイレが詰まった。 どうやらかなり奥の方で詰まったらしく、 男女共にすべてのトイレが使えなくなった。
こういう時こそ教会の雑用係を自任するビショップリック顧問(私)の出番である。
用具室から吸盤のついたアレ(なんて呼ぶんだっけ)を持ち出してきて トイレと格闘する。水は少しずつ流れているようだが、 なにぶん奥にあって圧力が届かないせいか、 どうにも流れが改善されない。
しばらく格闘した後、手の空いた人をつかまえて 二人で息を揃えて同時に圧力をかけてみた。
一回、二回、三回。...とうとう流れた。
みなさん、お疲れ様でした。
やはり、協力するものである。一人ではできないことも、二人ならできる(こともある)。
近隣に住む一族(＋帰省した弟)が実家に集合する。 総勢１９名。多いな。だんだん増えてるし。
おしゃべりをしながら昼食。 楽しかった。 子供たちも(特に年少の子供たちは)、かなり楽しく遊んでいたようだ。 普段は最年少のうちの末娘も、ここでは少々お姉さん顔をしていた。
その後、墓参り。掃除と雑草抜き。
解散。