日々の破片

_ なぜ、diffのpオプションが重要なのか

diffには、-pというオプションがあって、これを指定すると変更された関数名が含まれる。

例）

/tmp$ diff -u test.c test2.c
--- test.c      2007-06-15 01:12:37.886290094 +0900
+++ test2.c     2007-06-15 01:17:49.292036097 +0900
@@ -4,6 +4,9 @@
     for (i = 0; i < 100; i++) {
         n *= i;
     }
+    if (x) {
+        n ** x;
+    } 
     return n + x;
 }
 
/tmp$ diff -pu test.c test2.c       ← p付き
--- test.c      2007-06-15 01:12:37.886290094 +0900
+++ test2.c     2007-06-15 01:17:49.292036097 +0900
@@ -4,6 +4,9 @@ int foo(int x) {    ← ここに注目！！！
     for (i = 0; i < 100; i++) {
         n *= i;
     }
+    if (x) {
+        n ** x;
+    } 
     return n + x;
 }

別にあってもなくても影響なさそうに思えるわけだが。

で、なぜ-pを付ける必要があるかについて、nokadaさんがRubyKaigi前夜祭で力説してたのを思い出したので、メモ。

だっておれらが見てるソースはcvsヘッドだから-pが無いと全然わからないんだよね。

というわけで、ruby-devにパッチを送るときは、-pを付けようという話でした。

_ いまさら動的/静的どっちが言語の例のやつ

水島さんのとこを読んでて（もちろん、元（なのか？）のrubycoさんのところからだいたい読んではいたわけだけど）、こないだのRubyKaigiのテーマともからんで、多分、アジャイルな考えも入れて、そのあたりで思いついたことを書いてみる。あまりまじめには書かない。

さて、プログラムを書く人は、だいたい誰でも知っていると思うし、それゆえにケントベックの変化抱擁があれだけ受け入れられたんだと思うのだが、なにはなくても「自信」というのは、目的遂行には欠かせないものだ。

（ここには挿入しないが、能力ある−能力ない×自信ある−自信ない の4象限で相手の状況を分析し、それにあわせて適切な目的遂行のためのガイドをすることをリーダーシップと呼び、技術的にはティーチング、カウンセリング、コンサルティングの3種類の方法論を適用するというメソッドがあるのだが、「自信」っていうのは、つまりは気の持ちようなわけだが、「能力」と同程度に重要だという点が取り込まれていることはやはり注目に値する）

で、実際にプログラムを書く人にとって、自信の裏づけとなるのは、テストだ（もちろん、地力ってのはあるにしても）。

でも、プロジェクトの完了は、プログラマだけで行われるわけではない。さまざまな調整や管理が必要なほど（少なくても大規模であればあるほど）、その他の利害関係者は多くなるものだ。

彼らも彼らの自信の裏づけが必要となる。

テスターの裏づけは、なんだろうか？ テスト要項書とチェックマークかな。ユーザーの裏づけは、要件仕様書に書かれた内容や、プロトタイプの動作や、受け入れテストとか。あるいは、単に口うるさく会議をこまめに開きまくるってのも、すべては自信のためだ。大船に乗って……ってのは、自信がベンダーに対する信頼だけで成り立つ場合のみで、利害関係者が多ければ、全員がそういう気持ちになることはあり得ない。

めんどうだから、これで終わりにするが、静的言語の選択というのは、つまるところ、実際にプログラムを書くわけでも、テストをするわけでもないプロジェクトメンバーにとっての、自信の裏打ちだ、ということだ。したがって、間違いなく、本気で、「なぜ静的言語を選んだのか本心を教えてよ」と聞けば、「プログラマーが楽に（早く、正確に、デバッグしやすく、大して学習しなくても済む、とかいろいろな理由から）コードを書けるようにするためだ。それにより、スムーズに次のフェーズに移行できるし……ひいては、プロジェクトの成功に結びつく」というような答えが返ってくるだろう。

人間系においては、「自信」というのは、砂上に築かざるを得ない。

検証できないからだ。

したがって、評判とか世間様とか、常識（なんのかは知らん）に従うことは、すごいアドバンテージとなる。道に外れていないというのは、自信に通じる（それはそうでしょ？）。

逆に、自信がないとプロジェクトの成功可能性は低くなる。自信がない状態でプログラミングしたプログラムには間違いなくバグがあるってのと同じことだ（自信があってもバグがあるのがなんともゆくゎいなところではあるけれど）。

したがって、規模が小さく、デベロッパーとマネージャとカスタマーの結合強度が強ければ、当然、信頼度も高いので、このデベロッパーが選択したテクノロジーなら間違いないだろう、というプロジェクトの人間系の自信となり得る。

しかし、規模が大きく、顔も見たこともない、もしかしたら海の向こうのデベロッパーの進捗まで考える必要があるような場合には、評判や世間様や常識や定石を外れてそうなテクノロジーの選択は、まったく自信とはならない。というか、不安となる。だめだね。こりゃ、失敗プロジェクトだ。

JavaからRubyへ ―マネージャのための実践移行ガイド(Bruce A. Tate)

こいつが、ビジネス書だっていうのは、そういうことだ。ビジネス書は、ビジネスマンの血肉となり、つまり自信となる。デバッグもテストもプロトタイピングもできない世界で自信を保つには、自分自身による実績の積み重ねと、実績の積み重ねをした他人の教えの学習が必要だ。

というのが、実態ではないか、と僕は考える。

というわけで、この「自信」については、ダックタイピングがどうこうというのは、まったく問題ではない。それでは意味が通じないから自信となるわけがない。

（デベロッパー一人一人の顔が見えれば、その顔色を見て、自信となったり、逆に不安となったりするだろうから、規模の問題というのは正しい）

したがって、たとえば、IBMでもNTTデータでも良いけど、世間様の規範となりうる大きな人たちがたとえばJavaScriptだけで第8次オンラインシステムを構築して、安くて（開発のみならず運用＝実行時も）速くて、しかもカスタマーからの感謝の言葉と、日経BPの賞賛記事が出まくれば、大規模開発＝JavaScriptという動的言語による開発、っていう選択がプロジェクト全体の大きな自信となる。

あるいは、東証の新しいシステムがHaskellで作られて日経BPに賞賛記事が書かれて、稼動後1年なんのトラブルもなく、富士通（じゃないかも知れないけど）が成功事例としてそこらじゅうで宣伝しまくれば、大規模開発＝関数言語というか成功したHaskellによる開発、ってのが規範となり、その選択をすることが大きな自信となる（おそらく、最初にそのプロジェクトをGOした人たちはイノベータとして社内外で高く評価されることになる）。

だから、20年後には、（今、動的言語で自信を付け始めた人たちがヘゲモニーを握っているので）大規模システムはRailsで作られるようになるわけだし、そのころの若い開発者（まだ生まれてなかったり3歳くらいだったりする）は、「げー、動的言語で開発かよー、だっせー」とか「なんで関数型言語みたいな信頼性が低い（ということに、その時代の先端パラダイムではなっている）のを使わなくちゃならんのだー」とかの怨嗟の声が巻き上がるようになる。

そして、そこで「大規模開発は動的言語と相場が決まっているようだけど、なんで？？？言語は向かないってされてるのでしょうか？」というような疑問が出てきたりするのだろうな。

#大規模開発＝プロジェクトチーム全体で顔が見えない開発、と考えるとだいたい概念的にはOKではなかろうか。データベースのサイズとかクライアント数とか、コードの総行数は関係ない。GNUプロジェクトは大規模だけど、大規模開発じゃない（ESRによると伽藍建築だそうだけど）。いや、顔が見えないじゃなくて、利害が複雑で、プロジェクト全体の目的が曖昧になりやすい、というか末端の開発者がプロジェクトの全体の目的をわかっていない（教えられていない）開発を大規模開発と呼ぶというのが正しいかも。

#技術的には、ダックタイピングがあるから大規模開発に向かないというのは考えにくいと思う。interface継承（実体が伴わないから、どのような実装をも許容してしまう）があるJavaで大規模開発が行われているし、performで呼び出す名前の衝突がありえるCOBOLでも行われているというのがその証左だと考える。

#なんか、オチの部分は意図せずに、こないだ読んだ羽生さんの『Railsが普及した次の世界を想定すると……』みたいになってしまった。こういう輪廻転生みたいなというか、万物流転なことを言い出すってのは、ようするにそういうのを見てきたってことでもあるから、羽生さんも年を取ったな、ということなんだろう。でも、思うに、羽生さんもおれも、まだ次の新しいやつがくるし、その後にも次の新しいやつがくる、って見越しているから、来るなら来い、どーん！ とそれを受け入れ可能（使う/使わない/気に入る/気に入らない/知る/無視するという選択肢があるのは当然）だってことなんですな。