秘密じゃないよね。
Dave ThomasによるConstructor Methodの紹介ですが、 「コンストラクタをprivateにするのはどうか」という疑問の声を読みました (もう消えてしまったのでリンクできませんが)。
もちろんDaveがなにを考えていたのか分かりませんが、 私は「コンストラクタをprivateにする」価値があるケースはあると思います。
つまり、オブジェクトの複数の生成法があり、それぞれが同じように重要だった場合、 コンストラクタをprivateにしなければ、 「コンストラクタが採用している生成法がもっとも重要である」という 「正しくない暗黙のメッセージ」を与えてしまう可能性があります。 逆に言えばコンストラクタをprivateにすることにより、 「どれも同じように重要だ」という暗黙のメッセージを送ることになります。
良い設計というのは、こういう暗黙のメッセージが(意図してかどうかはともかく)、 うまく状況に即しているものではないのでしょうか。
経済産業省からお誘いのメールをいただき、さいわいにも東京にいたので、 経済産業省別館にて開かれた「Bruce Perensを囲む会」に参加しました。 お誘いのメールには「ランチミーティング」とありましたが、「ランチは出ません」とも書いてありました。 ランチタイムに開く会という意味だったようです。
で、行ってきました。言語は終始英語。 鵜飼さん、佐渡さん、八田さんなどをはじめとして(この業界で)有名な人もたくさんいました。
Perensの発表はなかなか説得力のあるものでした。たぶん、明日の内容と重複していると思うので、 どこかで資料が公表されるのではないでしょうか。
それから経済省のムラカミさんという方が話されました。
個人的には異論ありまくりなんですが、その点については後で本人と語りました(後述)。
集会後、Perensと個人的に話しました。
とかいうような話の後、Open Source Evangelistの備えるべき条件てどんなもんだろうか、 という質問をしました。
なるほど。Perens自身はElectricFenceやBusyBoxの開発経験があり、 また長らく映画業界(Pixer)にいたのでビジネスのことも分かるということなのでしょう。 こんな人、日本にいるかな。
最後にムラカミさんと話しました。私からは
というような話をしました。ある程度納得していただいたようで、 方針の転換を検討するという建設的な意見をいただきました。
いやあ、よかった。
山田祥平のRe:config.sysで引用されていた言葉に感動した。
今から五〇〇年前の中世ヨーロッパにでかけていって、グーテンベルグが発明した印刷術を評価することを依頼されたとしよう。たぶん、われわれは自信を持って、印刷術は普及しないと断定するにちがいない。その理由は次のようになる。第一に、印刷はきわめて高価であるから写学生の筆写に価格面で太刀打ちできない。第二に、ほとんどの人が読み書きを知らないのだから、複製を大量に必要とする市場がない。第三に、一五世紀当時は、本当に重要な問題は宗教に限られており、個人のプライベートな内面の思想の問題であったため、これは印刷物によって伝達できる内容ではない。それ故に、印刷術は絶対に普及しない。普通の観察力と判断力を持つ人ならば、かならずやそう断言したであろう。
[「アラン・ケイ」(アスキー、1992年)より、監修の浜野保樹氏の言葉]
いや、まったく。半端な知識は未来を予測するのに役立たない。
そして、未来を予測する適切な方法をアランは教えてくれる。
The best way to predict the future is to invent it.
(未来を予測する最良の方法は、それを発明してしまうことだ)
この言葉は僕の着ているＴシャツの背中にも書いてある。重要なのは新しいものを作ることだ。 たとえ、それが生き残らなくてもすくなくとも人類の多様性には貢献する。
日本人で世界で使われている言語をデザインした人は少ないようだ。 しかし、決して日本人が言語を作っていないとか、言語に興味がないと言うわけではない。
実際、この2週間ほどのうちで二人から「自分も言語を作りたい」という言葉を聞いた。 私に対するお世辞の一種である可能性もあるが、世の中「自分の言語を作りたい」という思いの人は 思ったよりもたくさんいるのではないだろうか。 『自分の言語の作り方』とかいう本が『コンピュータ・サイエンス』誌の別冊で出たこともあったように思う。
しかし、そういう人の中で実際に言語を作る人はそれほど多くないようだし、 ましてや、そういう言語が個人のおもちゃを越えて広く使われるケースはほとんどない。 ある意味Rubyは貴重な例外といえるかもしれない。私はラッキーだった。
しかし、「三人寄れば文殊の知恵」ではないが、新しい言語をデザイン(と実装)したい人が集まって、 意見や情報を交換し、相談するような場があれば、これから第二第三のRubyが日本から出てくることもあるかもしれない*1。あるいは、他の言語に影響を与えるようなアイディアが登場するかもしれない。
そういう場(メーリングリストとか)があれば参加したいという人は、 このエントリに(アドレスを入れて)ツッコミをいれてほしい。 あるいは直接私にメールをくれてもよい。
ある程度人が多いようならどこか適当な場所にメーリングリストでも作ろうと思う。
名前はlangsmith(言語鍛冶)かな。海外にもそういう名前のリストがあるらしい。
*1 ここで日本にこだわっているのは、私が日本語が一番得意という以上の意味はない
今日、散髪した息子との会話
私: 散髪してかっこよくなったねえ 子: かっこよくないっ 私: あ、「かっこいい」より「かわいい」って言われたいんだっけ 子: 「かわいい」でもないっ 私: じゃあ、どういうのがいいわけ 子: 「ふつう」がいい 私: そうなのか 子: うん 私: じゃあ、散髪してすっごく「ふつう」になったよ。とっても「ふつう」 子: (ぷいっ) 私: (あ、怒らせちゃったかな...)
普通って難しい。
書きつづける。何人かの人に書いた論文を見てもらう。 他人の視点で見ると自分では気がつかない問題があるものだ。
何度かコメントをもらううちに、 ようやく真の問題を把握できたような気がする。 しかし、把握できたからといって簡単に直せるわけではないのだ。 ぐすん。
家族と時間が取れなかったので、夕食は外で一緒に食べる。
Groovyも着実に進化している。JSR版では文法が変わったとの話だったが、 今回はじめて調べてみた。結構変わってるのね。
ブロックパラメータが {|x|..} から {x -> ...} になっていた。 これはPerl6((x)->{...})の影響か？ これはちょっと気に入らない。 あと、「...」が「..<」になったことも。
それ以外は妥当な変更かなあ。
しかし、MYCOM PCは最近オープンソースソフトウェアのリリースをちゃんとリポートしてくれる、Java系が多いけど。いずれにしても、ありがたいことだ。
評議会。聖餐会は司会。 日曜学校はルツ記。
任期が終わった宣教師が、両親と一緒に松江を訪問する。 ご両親に「宣教師として働いて、息子さんは変わりましたか」と尋ねたら、 「外見は変わらないけど、内面は成長したようだ」ということであった。 まあ、自分の息子が立派に責任をまっとうしたのを見るのは誇らしいことだろうねえ。
ワードの会員に英語でしゃべっているのを目撃されたのは 大変恥ずかしいことであったが。
米子でステーク神権会がある。移動。
ちょっと疲れが出て、うとうとしていた時間があったけど(ゴメン)、 おおむね
また、よく知らない人とペアを組んで、ロールプレイをする、という活動は 大変刺激的であった。
一部で根強い人気を持つPythonスタイルのインデントブロックを Rubyで実現するプリプロセッサ。
なにもそこまで、と思わんでもないが。
インデントブロックはそれ自身は致命的に悪いアイディアというほどではない。 タブとスペースの混在は面倒だけど、明確にタブを禁止するとか、手はいくらでもある。
だけど、 Pythonみたいに「それしかない」と式と文の明確な分離を招く(ブロックを含む式が書けない) ので、あまり賛成しない。Haskellみたいにデフォルトではインデントで、 必要に応じてブレースを使うというのがある意味理想的なんだろうけど、 同じことを記述するのに二種類ある冗長さは、Pythonな人たちは受け入れがたいのかもしれない。
あと、コメント欄とか掲示板とかでインデントが消えちゃうことが たまにあって、インデントブロックな言語だと情報が完全に失われちゃうのも痛い。 ブレースやendを使う言語ではインデントは冗長なので 復元可能なのに。
貧しさと豊かさの間に「不実の谷」があるという話。
小さなコミュニティだとひとりひとりがわかるから、 貧しくて貢献できないことはあっても「不実」は発生しない。 コミュニティが十分に豊かだと、けちけちする必要がないからやはり「不実」は発生しない。
しかし、コミュニティが半端に大きく、 かつ半端に豊かだと、「ひとりくらい水を混ぜてもバレないだろう」という 不実が自己組織化される。
うーむ。
人間の弱さと愚かさと考えるべきだろうか。 あるいは、これを克服することこそチャレンジだと考えるか。
コミュニティの機能不全については 「ネットコミュニティが崩壊するとき - GIGAZINE」も興味深い。
みんな「Rubyはすごい」って言うけどさ、 そんなにすごいってんならどうして
というような話。
どっちかっていうと文句は歓迎する。特にちゃんと根拠があるものについては。
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 2.0に入るかもしれない機能について述べていますが、本機能が本当に2.0に採用されるかどうかは、未定です。
「まだあるのか」とか思われそうだけど、まだあるんです。
今度は長年採用すると言いつつ、ほったらかしの最右翼、キーワード引数である。 調べたら、キーワード引数については、2003年のRubyConfではすでに話題にしている。 どんだけ前から口にしてたんだ。「やるやる詐欺」だな(苦笑)。
その時の仕様はこんな感じ。
def foo(a, b: 42, **keys)
p [a,b,keys]
end
foo(1) # => [1,42,{}]
foo(2, b: 5) # => [2,5,{}]
foo(3, b: 4, c: 6) # => [3,4,{:c=>6}]
まあ、そんなに悪くない。基本的にはこの線を踏襲しようと思う。 文法としては、ブロック引数の直前に
keyword: value,..., **keys
というキーワード引数を置くことができる、というもの。 Pythonと違ってキーワード引数は明示的に指定しなければならない。 通常の引数名が勝手にキーワードになったりはしない。
問題はrest引数と組み合わさった時。
def baz(*rest, a:4, b:0, **keys) ... end
として、以下の呼び出しを行ったらどうなるか。
baz() # rest=[],a=4,b=0,keys={}
baz(1) # rest=[1],a=4,b=0,keys={}
baz(a:1) # rest=[],a=1,b=0,keys={}
baz(a:1,b:2) # rest=[],a=1,b=2,keys={}
baz(1,2,b:2) # rest=[1,2],a=4,b=2,keys={}
baz(c:2) # rest=[],a=4,b=0,keys={c:2}
つまり、以下のルールに従う。
なお、※の部分はRubyConf 2005のキーノートで紹介したものと動作が違う。
この仕様ではキーワード指定はあくまでも通常引数の一部なので、 通常引数の引渡の時には *rest で受けて、 foo(*rest) と呼び出せばよい(はず)。
呼び出し側のキーワード引数は結局は引数リスト末尾のハッシュに過ぎないので、 呼び出し側では foo(**keys) のような文法は(本来は)不要。 ただし、対称性と型チェックのために採用する可能性は、なきにしもあらず(あんまり積極的ではない)。