もはやガーベージコレクション(GC)は必然だ。これから登場する言語でGCのない言語は考えられない。 世の中にはさまざまな(宗教上の？)理由でGCを毛嫌いする人がいるが、 そういう人はCやC++を使ってればいい。これらにGCが導入されることはないだろう。
では、Rubyのようなスクリプト言語のGCに対する要求にはどんなものがあるか。
Rubyの10年の経験からいうと速度に対する要求はさほどない。 Rubyインタプリタそのものが遅いせいかもしれないが、 10年間の間でGCが問題になったのは、
というlive objectが異様に多かったケースだけだ。報告があったのは数度だけ。 もちろん「GCが遅いなあ」って思った人はもっとずっとたくさんいるだろうけど。
だから、スクリプト言語のGCに対する要求はむしろ
などだろう。実はGCの研究はトータルの速度や応答性などの性能が重視されていて(当たり前だけど)、 この辺はあんまり検討されていない。が、実際の処理系にはこういうのが必要なのよ。
ところが、これらの要求は実は実現するのが大変難しい。
たとえば、(1)を実現するためには、 Rubyも採用しているCスタックをスキャンするconservative GCが向いているんだけど、 これは移植性が低くなりがちだし、なによりpthreadがカレントスレッド以外のスタックアドレスが取れないので、 native threadとの相性は最悪だ。(5)についても、木山くんがやったような世代別GCで大量live objectに対応できるが、普段の性能はどうしても低くなってしまう。
こういう相反する要求にどう応えるかというのが、これからのスクリプト言語の実装に対する課題ではないだろうか。 もっとも、そんなことは考えないでBoehm GCを使っちゃうってのも、この際アリだけど。
でもって、数年間考え続けてやっと
GC手法を考えついたような気がするんだけど、実装してみないと「普段の速度」は分からないなあ。 これが遅いとなんにもならない。
その手法の詳細を記述するにはこの余白は狭すぎる*1(続く)。
*1 期待させる口ぶりですが、たいしたことじゃありません
あいかわらず発散しぎみなのだが、 それぞれの分野で発散したまま議論が深まった。 今後、今までに出たいろいろなアイディアから取捨選択する必要があるのだろうなあ。
次回は3月5日(金)の予定。
朝から出席(でも遅刻した)。レポートは以下の通り
オブジェクト脳をなぜ作るのか
NECの牛尾さんとウルシステムの平澤さんとの対決。 しかし、21世紀になるのに「オブジェクト指向の三要素(カプセル化、継承、ポリモルフィズム)」はないだろう、とか思った。カプセル化も継承も本質ではない(それらを含まないオブジェクト指向プログラミング言語やツールはいくらでもある)。この中で一番本質に近いのはポリモルフィズムだけで、それは牛尾さん自身もお認めになっているようだ。
じゃあ、残りの二つはもういいじゃん、とか思ったのだが、じゃあ実際の例題を、 となったとき、Javaだとポリモルフィズムを使うのに、 継承(inheritsかimplementsのいずれか)が必須であった。 そういうことか。Rubyなら特異メソッド使ったりして直接ポリモルフィズムを体験できるのに。
あと、牛尾さんがオブジェクト指向を理解したのはファウラーの『リファクタリング』を読んで、 ということを聞いてちょっとショックだった。めちゃめちゃ最近じゃん。 Blue Bookを読んで(あれ、Green Bookだったかな)って私はもう「じじい」だな。
私自身は21世紀になってから、 (プログラマに対する)オブジェクト指向の教育には「コンピュータに置き換えないたとえ話は役に立たない」と思うようになったので、牛尾さんの話には同意できなかった。「オブジェクト指向という考え方は分かった気がしたけど、実際どう使ったらよいのかわからない」というのは、この「たとえ」が原因ではないかと疑っている。
はてなの作り方
ちょっと遅刻しての参加。私が聞いた範囲では「作り方」というよりも、 ユーザとの付き合い方、仕様の引き出し方のような話が中心だったみたい。 もっともこれらも広い意味での「作り方」の重要な要素なのだけれども。 きびきびした開発が心地よさそう。 話を聞いていて『4274065979』の5章「もうひとつの未来への道」を思い出した。洋の東西を問わず似たようなアプローチで成功しているなあ。
はてなの近藤さんとはんばあぐさんが同級生だったとは知らなかった。同級生でスピーカーしてたのね、今回。
スマートデータベースCachéの実力
「きゃっしゅ」ではなく「きゃしぇえ」と発音していた(最後のeの上にアクサンが付く)。 なんだか面白いもの。B-treeやXMLデータベースを連想する。 RDBを念頭に置いていると「データベース」と呼ぶのに抵抗がある。 もっともRDB以前は「データベース」という単語は違う物を指していたし、 私が前職で使っていたObjectStoreはもっと「データベース」らしくない。
Caché ObjectScriptとCaché Basicという言語を持ち、 データベースそのものがその言語のVMを持つというアプローチと 名前と値のペアを持つノードのツリー構成でデータベースを表現するのは面白いと思った。
でも、もうちょっと突っ込んだ内容が知りたかった。 言語おたくとしては上記2言語の仕様とかに特に関心がある。 展示会にもブースを出していないみたいで、カタログとか入手できなかった。
あと、性能についても「ほとんどメモリ上の処理なんで高速」とかで具体的な数字の言及は無かった。 データベースソフトウェアのマーケティングとしては不利ではないか。
My Framework作成の勧め: アプリケーションを３０個作る時には何を用意するか
前半は「お手製」フレームワークについて。 結局はTemplate MethodパターンとStrategyパターンの応用をフレームワークと呼んでいるような気もしないでもない。
「硬い」Javaで、「柔らかい」アプリケーション(たとえばWebサービス)を提供するために、 あまり変化しない部分から変化しやすい部分を切り出す苦労があるのだと感じた。 より「柔らかい」Rubyではそこまで必要性は高くないが、 修正は分散しない方が生産性が高いので、同じアプローチは有効だ。
後半はDIについて。C#でDIコンテナを作って解説していたが、 私の周囲の人の頭上に「？」マークが浮かんでいるのが見えるようだった。 もっとも、別の方法で解説するのは発表者の負担が大きいのだが。
全体を通じて久しぶりに「私の知らない世界」を見たなって感じ。 知らないところからいろいろと刺激を受ける。
あとはいろんな人と話ができたのも楽しかった。 「Ask the speaker」というコーナーがあったのだが、 聴衆はあまり聞きに来なくて、主にスピーカー同士の交流が行われていたように思う。 JAOOでも同じようなことが起きていたので(「このカンファレンスに来るといろんな人と話せるからいいんだよな」って言ってたスピーカー多数)、洋の東西を問わないのかもしれない。
それから、本イベント中、マイミク二人ゲット。
今回は扱いが良かったので、気分よく過ごすことができた。 関係者に感謝したい。
4274065979
以前のエントリでふてくされていたら、 今日の昼食で「謝辞に名前が載ってますよ」との指摘。 あわてて確かめたら確かに「Matz」と載っている。
ありたがいことだが、実質的に役に立ってはいないので、今度は過分だと思う。
午前中、長女の中学校の参観日だということで参加する。
普通の授業ではなく、ホームルームのような感じ。人権とか同和とか書いてあったので、どんな授業をするのか、と思ったが、その実態は一言で言うと「欠点も見ようで長所になる」というようなものか。
こういう活動をリフレーミングというらしい。このフレームは「フレーム問題」のフレームだな、きっと。
で、資料としてリフレーミング辞書なる紙が配られた。「頑固」が「自分の意見をしっかり持っている」などとポジティブに言い換えられた単語が並んでいる。これに基づいて生徒たちが自分と同じ班の人たちの「良い点」を探していた。なかなか興味深い活動ではある。私が中学生のころはこんな活動絶対にしなかったよなあ。
このリフレーミング辞書を逆方向に写像すると「悪口製造機」になるのは、思っていてもやってはいけないことなのだろう。
で、途中通りかかった中学校の図書コーナーには、さまざまな職業に対して『〜になるには』という書籍が並んでいた。若いうちからいろいろな職業になることを考えるのは良いことだ。私でも事情がわかる業界について何冊か眺めてみる。
『コンピュータ技術者になるには』という書籍では、結局は「コンピュータを好きなこと」くらいしか書いてないのだが、いろいろな会社の技術者にインタビューをしていて、コンピュータ技術者の生活実態がわかるのは良いことかもしれない。
ただ、取り上げられている会社が「コンパック」(HPに買収された)、「ロータス」(IBMに...)など、今は無き会社ばかりなのが、時代の移り変わりの速さを感じさせる。
『ウェブデザイナーになるには』という本では、 (株)オン・ザ・エッヂ社長の堀江貴文さんの写真が長髪で微笑んでいた。これも時代の移り変わりを感じさせる。
安来苑で開かれたRuby温泉ミーティング2006春に参加してきた。
４時からチェックインということで、４時すぎに会場に到着。さっそく温泉に入る。こ の旅館には何度も来ているのだが、そのたびにハックしてたり、話し込んだりしていて 、入浴したことがないのだ。今回こそは。
堪能した。
末娘が生まれてからはなかなか温泉に行く機会もなくて(歩いていけるのに)、久しぶり な気がする。
その後、食事と宴会。それぞれの料理には小さな鍋がついていた。私はカモ鍋だったの だが、苦手な食材(特に名を秘す)が入っていたため、イノシシ鍋と交代してもらう。
あとはあちこちで話し合いを進めたり、雑談したり。剣神ドラゴンクエストのプレイが 行われたり。
その後、サイボウズラボの竹迫さんが(主に)リクルーティングのプレゼン。いや、気前 のいい親会社があると違うなあ。負けじと(株)ネットワーク応用通信研究所の発表も行 われたが、施設や資本で見劣りがするのは否めない。温泉や豊かな環境やRuby三昧な仕 事は提供できるけど。
あと、私や前田くんやかずひこくんと仕事ができます、とか。うれしい人はかなり限定 されそうだけど。
それから、松江だけでなく東京でも募集しているので、生越さんや、ゆうぞうさんとも 仕事ができます。これも、うれしい人は限定されそうだけど。
さて、その他、目についたことを箇条書きに
I18Nは早々に入れる。
でも、まだこなれてないところがたくさんあるからなあ。一番気になるのはMarshalのフォーマットだがすっきり「非互換で構わない」という結論が。その他、正規表現の連携、文字コード変換・推測などもあるのだが、その辺も含めて1.9に取り込んで試すことに。
gcは入れない。
いろいろやってみたが、今よりも劇的に性能を改善できるものは無いため。
2/14にはCVSリポジトリにYARVブランチを取り込む。
でも、ささだくんが酔った上での発言だったらしいぞ。
個人的には非常に楽しかった。他の皆さんも参加を後悔しないくらい楽しんでいただけただろうか。
第一日曜なので証会。今日はなぜだか男性ばかりだった。
そのうちの一人、腹話術など多芸な人が 「何人の前でも緊張しないけど、この場では緊張する」と おっしゃっていた人がいた。
確かに。私も1000人の前でプレゼンしたこともあるけど、 その時よりも教会で60人の前で話す方が緊張するな。 今日も後で妻から「早口だし、声が小さいし、マイクからも遠いし、よく聞こえなかったよ」とたしなめられた。
すいません。
集会終了後、年度切り替わりの会計処理をしたのだが、 二件ほどミスをしていることを発見した。たいしたことはないのだが、 本部の人の事務処理の負担がちょっと増えるかも。
すいません。
帰宅したら、昼寝。ちょっとのつもりだったのに、 何時間も寝てしまった。
もったいない。
反省するべきことの多い日曜日だなあ。
一口に「初心者」と言っても、ただ単に経験が足りないだけの「真の初心者」もいれば、 「やる気」、「向上心」に欠けるので実力がいつまでも伴わない「自称初心者」もいる。 あるいは「真」と「自称」の中間に位置するとか。
で、やる気や向上心のない人は手のつけようがないので、ここでは扱わないことにする。
さて、初心者向け言語の話だ。
しばしば「初心者向けの言語」と宣伝される言語がある。 たとえば、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バッテリアプレットからはバッテリ容量が見えるのが不思議だ。