私: なんだってボクがこんなこと(啓蒙)しなくちゃいけないんだ。 妻: それ、誰かに頼まれたの？ 私: いや、そういうわけじゃないけど。 妻: じゃあ、それしないとアナタが困るの？ 私: いや、直接的には困らないだろうなあ。 妻: じゃあ、やらなくてもいいんじゃない？ 私: いや、そういうわけには。 妻: 結局、やりたいのね。 私: そういうことになるのかなあ。 妻: じゃあ、文句言ってもしょうがないわね。
昨日の「開発者と利用者」という文章について、 ツッコミをいただいた。意訳すると
ってことだと思う。「Rubyの開発に専念しろ」ってことかもしれない。 まあ、そっちの方が喜ぶ人は多いと思うんだけどね。
私は必要だと思ってる。
フリーソフトウェア開発者の基盤は脆弱だ。 ほとんどの開発者は自分の少ない余分の時間から開発時間を捻出している。 しかし、ソフトウェアが大規模化、高機能化し、複雑になってきたり、 ユーザーベースが増えていろいろな状況で使われるようになってくると だんだん片手間では追いつかなくなる。バザール型開発といいつつも、 結局は中心にいる個人への負担は少なくない。 少なくとも私はそうだった。
とはいえ 現状では、片手間で面倒見切れなくなったプロジェクトを抱える開発者の キャリアパス(っていうんだろうか)がない。 結局は、進化のスピードをゆるめるか、プロジェクトをあきらめるか、 誰か熱心な協力者が現れる幸運を祈るかぐらいだろう。
私は運がよかった。1997年、ちょうどRubyが片手間では面倒見切れなくなる直前に 今の会社に拾ってもらえたので。スポンサーの登場により、私はRubyの開発にほぼ専念できた。
しかし、今の日本にそんな幸運な開発者が何人いるだろうか。 今の日本に積極的にフリーソフトウェア開発者を(フリーソフトウェアを開発するために)雇用する企業が何社あるだろうか。
このままでは、日本からは
しか誕生しないことになる。いくら小さくて便利なソフトウェアも重要だとはいえ、 「ビジネス」ということまで考えると高機能なソフトウェアももっともっと必要だ。
これはよくない。 ソフトウェアの自由のある社会を実現したいという私の野望の大きな障害となる可能性がある。
だから、啓蒙する必要があるのだ。
いや、本当は私じゃない人がやってくれるのが望ましいわけで、 こーんな、
なんてなことは、他の人に任せたい。
私自身も最終的には啓蒙は「中間層」の人の仕事だと思ってる。 でも、
し、実際に期待するほどの啓蒙は行ってくれていない(ような気がする)。
まあ、フリーソフトウェアはタダだし、 手を伸ばせばタダで手に入るものに支援とか投資とかイミないよね、 という考えも理解できないでもない。
んが、このまま放置してたらトキみたいに手遅れになってから、 「フリーソフトウェア開発者を保護せよ」とか「レッドデータブックに登録だ」とかいう 話になるに違いない。いや、なればまだマシかな。
そういう危機になってはじめて本気になってくれるのかもしれない。 でも、その時までに失われてしまったものが取り返せるわけじゃないんだよね。
というわけで、「俺が代わりにやってやる。まつもとはRubyに専念しとけ」って名乗りを上げてくれる人が出るまでは、やっぱり続けないとなあ、と思う今日この頃であった。
いや、たいしたことはしてないんだけど、実際。
4839912653
『4839912653』、もうお求めいただけましたでしょうか。
お手元に『コードリーディング』がある方は、おもむろにカバーをはがしてみてください。 カバー裏には面白い(？)ものがあります。いや、たいしたモノじゃないですけどね。
ここからはネタばれ
私が島根なんて僻地に住んでいるものですから、監訳者全員が集まることは、 スケジュール的にも、予算的にもほとんど不可能でした。 だから、あのページの「某所」とは実はIRCだったのです。 それでも同時刻に集まるのが大変でねえ。
今日は司会なのだ。松江では2度目。まだ緊張しているのだ。 後で妻に「管理者」と「司会者」を言い間違えたよ、と指摘された。
月の第1日曜日は断食証会。 有志が自分の経験を短い時間で語る会なのだが、 クエーカー教徒にも似たような習慣があるそうだ。 200年くらい前に習慣の継承があったのかもしれない。
で、まあ、司会者はまず自分の経験を語るという慣習があるのだが、 これがますます緊張する要素だったりする。 まあ、妻の入院をネタにしてなんとか乗り切ったのだが、 毎回こんなに緊張していて大丈夫なんだろうか。 そのうち直るんだろうか。
今日は子供のクラスでも短いお話を依頼されていて、 どきどきした。わかりやすく簡潔な話を、と思えば思うほど思い付かないものだ。 子供達の前に立つまでなにを話すか考え付かなかったんだけど、 とっさの判断でルカ17:12から。
10人の病気の人がイエスさまに直してもらったけど、お礼を言いにきたのは一人だけでした。 直ったのがあんまりうれしくて、お礼を言うのを忘れてしまったのかもしれません。 みなさんも、周りの人やお父さん、お母さんに親切にしてもらったときには「ありがとう」を忘れないようにしましょう。
とかいうような話。幼稚園児もいたのでこの辺が精一杯か(私の能力が)。
というわけで、岡山に移動。
個人的には日大の吉開先生の 「ネットワークの価値モデルと、その応用に関する考察」という発表が一番面白かった。
ほ乳類の脳の容量とグループの大きさとの相関から、 人間が自然に構成できるグループの大きさは150前後と推定し、 それを基本にReedの法則を修正したものの、モデル化、という話。 マジックナンバー150はいろんなところに応用できそう。
そういえば、うちの教会の各支部もだいたい150くらいで頭打ちのところが多いような気がする。まあ、たいていはそれ以前に分割になるけど。
で、私の発表は「動的言語の古くて新しい世界」。 「最近、動的言語がはやってるみたいだけど、どんなもんよ」とか、 「でも、結局1958年生まれのLispにあることばっかりなんだよね」とか、 「Lispは一般受けしないんだよね」とかいうような話。
Lispを知っている人には受けたが、 Lispを知らない学生はぽかーんとしていたような。
来週の東大での話も似たようなものになるような気がするが、 もうちょっと改善しよう。
追記:
「未来の言語に大切なこと 〜動的言語の復権と将来〜」
概要
近年注目を集める言語はLispの機能を取り込みつつある。時代は 1958年を再発見しつつあるのか。なぜ、今Lispなのか。あるいは なぜ今はLispではないのか。また、プログラミング言語の(近)未来は どうなるのか。Ruby 開発者が独断と偏見にみちた予想(あるいは嘘 八百)を語る。
日時 2006年6月13日 13:30ー14:30
場所 東京大学 理学部 新1号館 小柴ホール
というわけで、朝から東京へ。 空港までの道がおもったよりも混んでいてちょとあせる。 とはいえ、ぶじに時間までに渋谷セルリアンタワー(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と話をしてて強く感じた。
いろいろためになるイベントであった。
Railsで作るWiki。ActiveRecordを使わずに ファイルベースでモデルを作ってるところがちょっと珍しいか。
Erlangで「並列数独ソルバー」を開発した経験から学んだこと。
「Rubyにはtail call optimizationがないから、状態機械の各状態を関数に変換することに抵抗がある」という指摘がある。実はYARVにはささだくんがtail callを直すコードは入れてくれているのだが、デフォルトではオンになっていない。ここにオンにした方が良い理由はひとつ。
Erlangっぽい並列ライブラリへのニーズはそれなりに高そうだ。 Multi-VMを使うのか、Multi-Process＋プロセス間通信を使うのかは別として。
マルチコア利用はプロセスでいいかも、という話なのだが、 コメント欄に驚異的な情報が。
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恐るべし。
会場から羽田へ向かう京急に乗っていたら、気がついたら天空橋を京急蒲田に向かっていた。 どうやら、うとうとしている間に電車が羽田空港を出発してしまったらしい。 しかも、そういう時に限って快速で空港線の途中の駅に止まらないし。
すごい、あせった。
が、蒲田から引き返しても飛行機には間に合った。 ちゃんと余裕をもって行動しといてよかった。