ユーザ・サーバ数が無制限のライセンスも低価格でご利用いただけます。
本番。ホテルから歩いて北大、クラーク会館まで移動。
いろんな人が来ているので御挨拶。 高橋さんもいらしてた。 日本Rubyの会はYARVのポスターとRailsによるブログツールTypoを展示していた。 TypoはAjax風味の表示が結構すてき。
日本Rubyの会の展示の隣はZopeが展示していた。 展示していた人は、私の顔を知らなかったようなので、 以下のような会話が交わされた。
展: プログラミングはなさいますか
私: ええ、すこしは。
展: 私はプログラムしないんですけどZopeは便利ですよ
私: Pythonの文法は知ってるんですけど
展: 使わないんですか
私: あんまりPython使わないですねえ。
展: 宗教上の理由とか(笑い)
私: いや、そーじゃなくて仕事上というか、立場上というか(苦笑)
展: そうなんですか(真顔)
...以後、ZODBに関する面白い話が続く...
そうこうしているうちにお昼になって、 スタッフの人が呼びにくる。「まつもとさん、こっちこっち」。 言われるままについていくと、 北大の敷地内芝生にビニールシートを敷いて、 七輪並べてジンギスカンを始めている。
なんとのどかな。
私の母校も敷地の広さでは負けないと思うのだが、 そんなのどかさはなかった。 私の発表は午後一番なので時間の余裕はなかったが、 しっかり堪能した。 しかし、私の一族のマスコット動物は羊なのだが、 それをよろこんでばくばく食べるというのはいかがなものか。 母親あたりにひどく怒られそうな気がする。
で、午後は発表。スライドはここ。
ま、わりとふつーの発表。なんかどこかで聞いたような話が多いけど、 まあ、こういうイベントは北海道では珍しいだろうから、 基本的なことから。基本的すぎて聴衆がどう感じたのか不安だったが、 数人に感想を聞いた範囲内ではおおむね好評であった。
発表終了後、松江に置いてきた妻子とSkypeで話をしてから、 北大博物館へ。やっぱりここまで来たらマンモスを見ておかないと。 次女が「どうしても見てきてほしい」ということだったし。
展示はこじんまりとしていたが、貴重な資料がたくさんあって、面白かった。 閉館直前であったがしっかり写真も撮ってきたし。
その後、みんなで移動して懇親会。そろそろ疲れが出てきていたが、
などなどについて。
懇親会終了後、みんなが「じゃあ次だ」と移動を開始する。 9時過ぎに会場を出て、予約が10時だということで、 「じゃあ、それまでラーメン食べにいこう」とかいう人までいる。 この人たちの胃袋はどうなってますカ？
と思ったが、実際に二次会の会場(石鍋屋)に着いたら、 ジンギスカンやらモツ鍋やらばくばく食べてしまう。おいしい。 私の胃袋もどうにかなってますヨ。
食べながら、Rubyは金の匂いがしないとかなんとかいう話もする。 そのうち、うち(NaCl)が「Rubyで10倍の生産性」とかなんとかプレスを打って、 世間の注目を集めたらちょっとは状況が変わるかな。変わらないような気も。
酔えば酔うほど高くなる高林さんの声。大企業の中の人は大変だ。
三次会に行くという人もいたが、 それは振り切って、東横インへ。ロビーの無線LANを使わせてもらいつつ、 morqのハックを。それから歩いて自分のホテルに帰り着いたのは夜中の2時をはるかに回っていた。
後輩が「月曜日にはどうしても必要なので」とせがむので、 morqをハック。今まで基本的にEstraierをベースに検索していたのだが、 当初の構想の通りRast上で動くように変更した。 で、前田くんのximapdを参考にさせてもらいつつ、ごそごそやっていたら、 1時間ほどで完成。東横インからホテルへ移動。
しかし、そこでマシンがハング。 そういう時に限って /tmp で作業していたりして、 1時間の成果を失った。出張中だし、夜遅いしでちょっと気が焦っていたのだろう。 普段なら致命的なファイルを /tmp に置いたりしないのに(本当か？)。
いずれにせよなくなってしまったものは帰ってこないので、 再挑戦。一度実装しているので今度は20分ほどでとりあえず動く。 何回か試してバグをとりのぞくとうまく動いているようだ。 完成したのは4時前だった。
OSC2005-DOの会場で高橋さんたちとした話。
なぜ私はいつまでたってもテスト駆動アプローチを習慣にできないのか、 改めて考えてみるとやはりドライブ感が原因のようだ。
「なにかを作りたい」と思った時、 テストファーストなら「そのなにかをテストによって表現する」わけだが、 私はその作りたいものがコードとして脳裏に浮かぶのだ。 そこでテストを書いていると、その浮かんできたコードがどこかへ逃げてしまうような気がする。 脳裏に浮かんだコードが消えてしまわないうちに、 素早くタイプして書き留めてしまわないといけない。
いわば「イタコ系プログラマ」。
いや、言い訳なんだけどね。とりあえずコードを打ち込んでからでいいから、 ちゃんとテスト書こう。
末娘が熱が出たとのこと。突発性発疹の疑いとか。出張中に限ってこんなことが。
Ruby2.0といえばK&R CからANSI Cに移行しないのですか。ソースコードがK&R Cなのは、新規開発者参入に際して、大きな障壁になっていると感じます。わたしもnkfを触っていなければK&R Cはいじりたくありませんでしたし、先日も何人か友人を開発に誘ったらK&Rだからイヤとか、そもそもK&Rはわからんとか言われまして・・・。
「K&Rで発見できないバグがある」ならわからないでもないですし、「イヤ」というのも趣味なので理解できますが、「K&Rはわからん」というのはいかがなものかと。
なお、以降の予定はありません。でもstaticのものも含めて全部の関数にプロトタイプはつけるようにしようかなあ。
まつもとさん，サイン，写真ありがとうございました．
まつもとさんの世代ならK&RもANSIもわかって当たり前であり、確かにK&Rがわからなのはいかがなものか、というのは成り立つでしょう。しかし、わたしの世代ではK&Rなコードを触れる機会は著しく減っており、K&Rの解説書はRubyの解説書より少ないのが現状です。情報系の友人曰く、C言語について習っても、それは全てANSI Cであって、K&Rは触れられすらしないそうです。また、古い文献やコードを見ればよいといっても、なぜ今更K&Rという後ろ向きな感覚は消せません。実際わたしもnkfをいぢる前にRHGを見たときはRubyがK&Rってだけでコード見るのを放棄してましたし。このように、K&Rであることが、‘わたしの世代においては’まつもとさんの想像以上に参入障壁になっていると考えます。
あと、ANSI CだとC++のコンパイラを通るので、C++のSDKしかない某国産OSへの移植がK&R Cに比べ格段にしやすい、なんて話も聞きました。
「ANSI CだとC++のコンパイラを通る」ってことはないでしょう。
K&Rってそんなに違うの？ 解説書がいるほど？
すくなくともRubyの使ってる範囲内では関数の引数宣言形式が少々違うだけです。それを「解説書がないから」と思ってしまうのは、「私の世代では」とかいう問題ではないと思います。私(たち)が年寄りなのは認めますけどね。
残りの点も事実誤認でしょう。RubyはVC++でコンパイルできますし、逆にK&Rも理解できないような(本当にC++しか理解しない)コンパイラならANSI Cでもだめでしょう。
ANSI Cに良い点があるのは認めますし、K&R風引数宣言はもはや単なる趣味の問題なので、移行してもいいかな、と思う気持ちもないでもないですが、事実誤認や先入観に迎合するという理由ではイヤです。
僕も，K&Rが，そんなに目くじら立てるほど，ANSI C と異なっているとは思えないですね．それに，世代の問題ではない事も同意です．私は，20代前半ですが，K&Rは10代の頃から知ってました．
むしろ，読む気があるなら，そして，それがK&Rであると知ってるなら，何も障壁は無いと思うんですけどね．
私も自分のためのプログラミングだとテスト駆動できません…
＞ naruse さん
まず、“私の世代”と、“まつもとさんの世代”の違いを明らかにしてください。えっと、平成世代 vs. 昭和世代 とか。
それで、K&R と ANSI C って、そんなに違うんでしたっけ？関数の宣言の書き方が異なるくらい、の認識しかなかった（。.ヾ
私なぞはいっそ C99 のが楽で良いやって口なのですが、
K&R で書き続けてるのってコンパイラの互換性の他に何か合理的な理由があるんでしょうか？
ANSI のが K&R(1st edition) に比べて型チェックが厳密なんだと理解してるんですが、もしや Ruby のような型付けの弱い言語だと K&R のが相性が良いとか、、、(だったら面白いなぁ、、、と妄想)
そんなこたあないですね。> K&Rのが相性が良い
型チェックについてはちゃんとキャストしてますし。
Rubyを作ってた当初はK&Rしか解釈できないコンパイラがまだ残っていたのと、私がANSIスタイルの引数括弧の長さが嫌いだというのが理由です。
Jittaさんへ。SunOS4を見たことあるかどうかではないでしょうか。
それか「ぼくらが生まれてくるずっとずっと前にはもうアポロ１１号が月に行っていた」かどうか。
....年寄り自慢は自虐的だな
＞まつもとさん
K&RとANSIの違いの大きさについては確かに誇張がありました。
また、C++は和製OSで使っているようなレベルでの話ですので、話を出すのは不適切でした。
解説本の話を出したのは違いの大きさでなく、
K&Rの今の、そしてこれからの知名度を出したかったからです。
今この日記を読んでる方はみなさんK&Rのコードを触ったことがあるでしょう。
でも、明日rubyのソースを見る人は、それがはじめてのK&Rなのかもしれません。
最近のC言語の解説では「K&R」という単語自体が載っていない事もあるので、
K&Rであることすらわからないかもしれません。
そんなレベルの人はいらない、というのならいいのですが、
ただでさえ参入障壁の高いrubyでそれも寂しいしなぁ、と。
＃MLベースなこと、リファレンスが難しいこと、コミッタになるのに大阪まで行かなければならなかったこと。
＃CVSであることも、将来的には障壁になるのでしょう
＞Jittaさん
わたし自身は20で、サンプリングは18-24ですね。
nkf2を投げた頃はまだ未成年で、Kazuhikoさんにいぢめられたな・・・（笑
しかし、平成時代も念頭には置いています。
ANSIより先にK&Rに触れている世代、というのは一つの区分でしょうし、
将来的にはruby以前にK&Rに触れている世代ってことになるのかな。
なかださんのところでも見かけましたが、SunOS4に付属のコンパイラはK&Rなのですね。
これでも通したいから、というのならわかります。
> 型チェックについてはちゃんとキャストしてますし。
ここ、もう少し詳しく。
naruseさん、なにかを指摘しようとしているのは分かりますが、やや的外れではありませんか。
たとえば「コミッタになるのに大阪まで行かなければならなかったこと」がなにを意味するのか分かりませんが、それはnaruseさんに固有の事情だと思います。私と会ったこともないのにコミット権をもらっている人はたくさんいます。まして、一般にコミッタになるためにどこかに出かける必要があるわけではありません。
また、MLベースなことやCVSであることに不満を感じる人や、それが理由で参加を躊躇する人が将来いるかもしれませんが、それは現在参加している人に変化や不便を強いる程のものではないと思います。っていうか、私個人は開発に関してメーリングリスト以外の(特に掲示板のようなpull型の)メディアで議論する気にはとてもなりません。中には2chをベースにソフトウェアを開発している人もいると聞きますが、よくやるなあってのが正直な感想です。CVSはねえ、psvn.elの使い勝手が唯一の障害ですね。
正直なところ、ユーザはともかく、コア開発者の参入障壁をあまり下げてもなあって気はします。
SunOS4についてですが、実はANSI styleが一部紛れ込んでいますから、今でもコンパイルできなくなってるはずです。気づいたら直すようにはしてるんですが。
通りすがりさんへ。ずっと昔は引数の型チェックが行われないことを利用して、呼び出し側はVALUEで受け側はstruct RString*のようなことをやっていたのですが、今は止めました。
私が書いた ANSI C なコードについては直すまえに議論をお願いします。
私が ANSI C で書くのは [ruby-dev:24834] に書いたとおり意図的なもので、
その意図は [ruby-dev:24489] や [ruby-dev:24624] などの実際の経験にもとづくものです。
中の人は当たり前だと思っているところに、外の人の参入障壁がある、というのが趣旨ですね。
MLは、趣旨は以前の日記でわかりました。
Mozillaの開発からも似た話は聞いたことがありますので。
あちらのBugzillaはアカウントを作らせることでpush型に近づけているようです。
なお、掲示板系もビューワを使えば、使っている人にはpush型になるのです。
akr さんが言っている引数の数の問題は、上の方で Matz さんが、
> でもstaticのものも含めて全部の関数にプロトタイプはつけるようにしようかなあ。
と言っているので、解決じゃないですかね。
プロトタイプ宣言があれば、定義が K&R スタイルでも、コンパイラがチェックしてくれますよね、たしか。
> SunOS4を見たことあるかどうかではないでしょうか。
むむ！！初めて仕事をしたのが SunOS4 でした。では、私が短大ではなく、４大へ行っていたり、４大に編入したりしていれば違う世代になったのですね！！もっとも、 SunOS3 も、見てはいます。
> わたし自身は20で、サンプリングは18-24ですね。
っ！１０年以上差があるのね(--;
おふざけ終わり：：：
それで、私は SunOS4 を、『プログラミング言語Ｃ 第２版 ANSI C 対応版』を片手にプログラミングしていたのですが、そんなに…習得の障害になるほど違うのでしょうか？Solaris 2.3 で、ANSI C に沿った書き方をしよう、と思ったときに気をつけたのは、ヘッダファイルなどに書く関数宣言のしかたぐらいだったのですが。。。
お、「k&r ansi」でググると、こんなページが出てきた。
http://docs.sun.com/source/806-4836/compat.html
でも、、、実際使ってます？こんな違いを引き起こすような書き方。
wiki で、Ruby の ML から、K&R と ANSI の話をピックアップされている方がいらっしゃいますね。
http://pub.cozmixng.org/~the-rwiki/rw-cgi.rb?cmd=view;name=K%26R+%A4%CA%B4%D8%BF%F4%C4%EA%B5%C1
でも、ここで問題として上がっているものは、『そもそもK&Rはわからん』という問題ではないと思います。コンパイラが指摘してくれるはずのミスが摘出されない。これによってデバッグが面倒になる。だから ANSI の書き方が良い。ならわかりますけど。
> コア開発者の参入障壁をあまり下げてもなあって気はします
賛成です。って、Ruby の開発者じゃありませんが。私は Microsoft から MVP 表彰を受けていますが、そんな表彰制度を導入して外部の人間にサポートさせなければならないほど、開発者の質が下がっている、とも言えますから。
> でも、、、実際使ってます？こんな違いを引き起こすような書き方。
それはSun Cの事情ですね。K&R/ANSIじゃなくて移植性を考えたら普通避けることばかりでしょう。
> 整数定数の接尾辞 u と U はサポートされない。
え、そうだっけ!?
わたし自身は、習得の障害というよりも、本能的にその些細な違いが怖い、です。
基本的には関数宣言だけということは知っていますが、自分の知らない他の違いにいつはまるか怖いのです。
コンパイラがミスを指摘してくれない件についてはakrさんが既に指摘なさっており、わたしが言い添えられることはありません。
わたしはそれとは別の見解を提供したかったのですよ。
「他の違い」というのは本当にK&RとANSIの違いが主ですか?
プラットフォームごと処理系ごとの違いではなく。
そこは本能的な予感なので、実際にはまるのは処理系の違いになるのかもしれません。
ささいな違いが大きな違いを生む予感というのは大切にしたいのですけれど、
移植性に気を使うことを考えたら、新旧規格の違いなんて誤差の範囲のような気もしますけど。
とりあえず、こんなのありますよ。
http://www.kouno.jp/home/c_faq/c11.html
どうも。はじめまして。crowbarの作者兼迷教科書の著者です。
>でもstaticのものも含めて全部の関数にプロトタイプはつけるようにしようかなあ。
関数定義をANSI C以前の形式で記述している場合、下手にプロトタイプ宣言を付けるのは危険です。たとえばfloat型は、ANSI Cでプロトタイプ宣言をしていればfloatで渡されることが多いと思うのですが、古いCでは常にdoubleで渡されます。下手にプロトタイプ宣言をして、関数の定義側でそのヘッダファイルを#incudeしてなかったりすると、呼び出し側はfloatで渡すのに呼び出され側はdoubleのつもりで受け取ろうとして、ちゃんと受け取れないという事態が発生する可能性があります。
処理系によっては、エラーが出るはずです。
まつもとさんはこんなことはご存知かとは思うのですが、変に間違った知識が広がるのもどうかと思うので。