Diary?

2008-08-21
Thu

(00:33)

新しい仕事の話をするために待ち合わせ場所にいったら、ピンハネ業者の男が現れた。ちなみにそいつは服装も言葉遣いも頭も悪かったという
そのピンハネ業者の男に指示されて別の場所に向かったら、第二のピンハネ業者の男が現れた。そいつは頭は悪かったようだが、最低限の身なりと言葉遣いはできていたという
実際の仕事場に付くまでに第三のピンハネ業者の男が現れ、ようやくまともな仕事の話になった
その日は最終的に一次請けの人間とも会ったが、その仕事は目に見える範囲だけで「顧客」「一次請け」「二次請け」「三次請け」「四次請け」というレイヤーがあり、つまり五次請けの仕事が回ってきたということらしい

……いや、俺の話じゃないよ? ま、こういう事もあるってわけよ。

(01:08)

薬のおかげでだいぶ症状は落ち着いてきたけど、まだ多少咳が出るな。それでも日常生活というか研修で指導するのに支障のでるレベルじゃなくなったんで、まあいいか。でもこれ、薬の服用止めたらまた元に戻るような気がするなー。何にせよ再来週にもっぺん検査するっぽいので、それまでは何とも言えないか。

(20:28)

ぬー、やっぱ次の仕事は C# か? まあ、コンペで勝たないと取れないわけで、今からグダグダ考えていても埒があかないんだけど。というわけで、今日は Java と C# の簡単な比較表を作る羽目になった。まあ、あくまでも A4 一枚で収まる程度の軽いものだったけど。

しかし C# の言語仕様で究極的に理解不能なのが null 許容可能にできるプリミティブ型だ。これは最悪だ。何が最悪って、 null こそ近代プログラミング言語が解決しなければならない問題であり、というのも無思慮な null の使用はソースコードの可読性、メンテナンス性、デバッグ性を急落させるからだ。たとえ型宣言のある言語であっても、戻り値として null が返された瞬間にその情報を失ってしまう。そして null 参照による例外のスタックトレースに、当然 null がどこに現れたかは出ていても、どこから null がやってきたかは書かれていない。というわけで、俺は null が無条件に参照型の値になれる言語を安全などとは認めていない。

この null 問題の解決方法はないわけではなくて、その一つが DbC 、契約による設計だ。これは Java でも AspectJ などでできるが、俺はそういったサードパーティのライブラリなしでは契約プログラミングのできない言語はいい加減滅ぶべきじゃないかと思う。確か Sun はアスペクトは決して Java に取り込まないとか言ってた気がするけど、既に現状 Generics とかで複雑化してるんだからもう取り込んじまえって感じだな。ま、とりあえず実際にやると次のような感じになるかな。くだらない例で悪いけどさ。

//Test.java
public class Test {
  public static void main(String[] args) {
    System.out.println(new Test().foo());
  }
  
  public String foo() {
    return null;
  }
}
 
//Dbc.aj
aspect Dbc {
  pointcut atFoo(): execution(String Test.foo());
  
  after() returning(String s): atFoo() {
    if (s == null) {
      throw new RuntimeException("foo");
    }
  }
}

AspectJ を使ってコンパイルして実行すれば、実行時例外が投げられるのがわかると思う。元のソースファイルにアスペクトというか契約の情報が出てこないのが極めて気にくわないが、そこら辺は開発規約とチェックツールで頑張るしかないか。もっともこの辺の話を理解してついてこれる開発者が現場にあんまりいないので、実践で有効なのかどうかのチェックすらできていないのが情けないのだが（別に難しい話じゃねえだろうに）。

俺的にこの問題に一番有効な解法を与えていると思うのが Haskell で、 Maybe モナドなどをみると代数的データ型とモナドの組み合わせの強力さがわかる。やはり強い型付けとか型安全性を謳うならこのぐらいやってくれないとな。もっとも Haskell は俺も使いこなせないので、さらに実戦での有効性が不明なんだけど。

とにかく、いい加減何も考えずに null を使うのはやめにしないか。こいつはプログラミング言語のセマンティクスに現れた特異点であり、この世界の邪悪の根源であり、ドラムバッグ一杯につまったクソ虫だ。特にバカでかいフレームワークを読み解いている最中に null 参照で死なれると、本当に追うのが厄介な事が多いんだよ。

そういや C# の null 許容可能プリミティブ型の説明でデータベースの null 値とプリミティブ型の間のインピーダンスミスマッチがどうのこうのという話を読んだことがあるけど、データベースにおける null は汎用のプログラミング言語における null 以上の厄介者で、端的に言えばハルマゲドンをもたらすものだ。関係モデルにおける null というか三値論理のヤバさについては「3値論理 —— 神のいない論理」が大変参考になる。というわけで、可能な限りすべてのカラムに NOT NULL 制約をつけよう。

追記：じゃあ null 使っちゃダメなら何使えばいいんだと言われそうだが、 NullObject 使えって感じだな。

追記2：文脈でわかると思うけど、上で書いてるデータベースってのは RDB のことね。

(22:40)

そういやバーチャファイターの新バージョンについて何も書いていなかった気がするので、とりあえず何回か遊んでみた感想を箇条書きにて。

相変わらずゲーム性がマニアック過ぎ。鉄拳よりも操作性は好きなんだが
複雑度のインフレは当然治まっていないので、完全に初心者お断り
というか俺みたいなフラッとゲーセンに立ち寄る程度の人間にはかなりキツい
相変わらずカードを作っていないと遊んでくれる人が激減する
新キャラのジャン紅條が空手使いだったので、カードはジャンで登録した
- 前作で持ちキャラだったゴウは俺の主力技が変更されたりなんだりしていて萎えたので使わない方向で
正拳突きで突撃して二択を迫るのが基本らしい。空手らしい重い打撃をブチ込むのは楽しいが、いささか上段攻撃が多すぎないか
技の多くが直線的なので、どうも軸移動の上手い相手にはキツそうだ

結局今回もやり込む暇なんぞなさそうなので、あっという間に脱落しそうだ。