Diary?

(18:54)

俺は基本的にバカからリンクを張られた場合何もしない。何故なら、バカの相手を真面目にしてると、はたから見るとどっちがバカだかわからないからだ。それにほら、俺がわざわざ何か書かなくても、バカに感化されるやつってまず殆どいないじゃん? が、今回は少々トサカに来たので例外。

• 2008,01,28 メモ

科学は宗教では決して無いが,科学も宗教も元々は同じ物。我々人間は「分からない物」にあれこれ解釈を加えたがるので,科学も宗教も色眼鏡のひとつでしかないことは理解してほしいと思う。

「科学も宗教も元々は同じ物」までは紛れもなく歴史的な事実なんだが、その後は何だ? 「科学も宗教も色眼鏡のひとつでしかない」だって? 正気かよ。だったら何だ、「地震は地殻の変動が原因」というのも「地震は大ナマズが引き起こしている」というのも同じだってことか? それは明らかに違うだろ。まあ、確かに「大ナマズが地震の原因なんだよぅ」と言い出すのは完全に自由だ (その程度の言論の自由はこの国にもあるからな)。だけどよ、まともな学説と同列に扱いたいのなら証拠を持ってこいよ証拠を。いいか、「解釈の違い」までなら「趣味の違い」とまったく同じ話だからな。ていうか俺、「そしてこの問題が最悪に厄介なのは、こっちが『正しいものだと認めて良いか』を問題にしているのに、あっちはそんなことは問題にしておらず、むしろとんでもないことを信じることでより強く結束していることだ」って書いてるよな。お前も引用してるよな。何でそこで宗教と科学を同列視するような言葉が出てくるんだよ。

ちなみにこういうバカがソフトウェア開発の現場にいるとどうなるかっていうと、

• バグの原因をきちんと探らずに適当な修正をしてみる (原因を探るためにコードを書きかえているわけではない)
• 計測をろくすっぽせずにボトルネックの位置を決めつけてパフォーマンスチューニングをおっぱじめる
• 自分にとって都合のいい前提条件のコードにこれまた都合のいいテストを通して終わり
• 自分のところでコンパイルとテストが通ればよく、他の部分との整合性とか全体のデザインはガン無視
• 動作確認せずにリリース

その他諸々、とにかく害悪でしかないんだ。上の奴は全部俺が見てきたケースだし、いくつかは俺自身大学時代にやらかしてえらい目にあったことでもある。そして本人は「自分はそれでいいと思った」と言い出すんだ、一つの例外もなくな (いや、まれに黙りこくる奴がいるな)。いいか、確かにとある現象を勝手に解釈するのは当たり前だが自由だ (ブレインストーミングなんかではむしろ普段出てこない電波な意見が貴重だしな) が、それらの中で客観的で妥当な証拠を欠いたものは信用するに足るものではないんだからな。いいか、たとえ自分にとって気にくわなかったり都合が悪かったりしても、それが明らかに正しいと判断できるものなら受け入れる必要があるんだ。俺の後輩には気にくわない、直観に反するという理由だけで量子力学を否定してるアホがいたが、お前はそのアホと同じだ。

いいか、科学は断じて色眼鏡ではないからな。むしろ色眼鏡をパラノイアに陥るまで取っ払う必要のあるものだからな (実際のところこれは本当に難しく、思わぬ見落としが無数にある)。俺が学んだものは確かに「計算機」で修飾されるし、そもそも選んだ道が理論屋ではなく実装屋ではあるのだけど、少なくとも大学で 4 年間科学を学んだものとしてそこは頭から否定させてもらう。

(20:43)

今さっきコンビニでカップスープを買ってきたんだけど、なぜかスプーンじゃなくて割り箸が入ってる。

……勝手にその店員はスープを箸で食べるプログレッシブな習慣の持ち主と断定。

(23:13)

本日のちょっとびっくりコード。

Object[] result = foo.bar(arg);
ClassA a = (ClassA) result[0];
ClassB b = (ClassB) result[1]; // ClassA, ClassB はクラス階層上では無関係

どうも Java で多値っぽいことをやろうしたが、

• Java は多値をサポートしてない
• Java は静的型付けなのでヘテロジーニアスコンテナが作れない (型安全性を考えるなら当たり前か)
• 標準ライブラリに Pair や Tuple がない
• プロジェクトの規約が厳しい上にアホで、中間データの受け渡しのクラスですら自由に作れない <- どう考えてもこれが一番の原因だけどな

というわけで、 Object の配列にしちゃったんだろうなー。ってこれはねえよ。何のための型付けだよ。俺は可能な限りそのための構造体クラスを作ろうとは思うんだけど、前述のとおりプロジェクトの方針で禁止されている。なので別解を考える必要があって、もしも foo が状態を持っていいのなら、

foo.bar(arg);
ClassA a = foo.getA();
ClassB b = foo.getB();

っていう解法もあるけど、これだと a, b が作られる処理が一連のトランザクションだっていうことが曖昧になる危険性があるので、俺はあんまり使わない。それに、 foo が状態持っちゃいけなかったら終わりだしね。というか俺は本当は次のように書きたい。

a, b = foo.bar(arg);

ただ、これだと a, b の型をどう表現するのかって問題がある。一番何も考えていない案は

ClassA a, ClassB b = foo.bar(arg);

という文法なんだけど、これはどうだろう。ちょっとこれは気にくわないし、型名を先に書く言語になれた人の場合 a と b がともに ClassA という風に錯覚してしまうかも (さらには ClassB を変数だと錯覚するかも)。なのでやっぱこれはダメだ。ある程度名前が長くなってくると相当読みにくいコードになりそうだしな。なので結局は次のようにするしかない。これは全然許容範囲内。

Pair<ClassA, ClassB> result = foo.bar(arg);
ClassA a = result.first;
ClassB b = result.second;

それでも問題は解決してなくて、もしも三要素の戻り値を扱いたかったらどうすんの? これについては檜山さんの「型パラメータと総称：どうしたらわかりやすい構文になるのかな」が参考になる。総称とか Generics の機能のある言語だとこういう問題に直面するんだよな。その点動的言語は悩む余地があんまりないので、気楽っちゃ気楽だ。もっとも仕事で使うのは今のところ十中八九 Java なので、考えないわけにゃいかないんだよな (それに俺は本当は強い静的型付けの方が好きだし)。