モデリングの難しさ

久しぶりに、どかっと熱が出る風邪を引きました。先週辺りから寝ている時の肩の冷えが気になって、気をつけないといけないなと思っていたのですが、今週に入ってのどが痛くなり、木曜日には鼻水がだらだらと出て、金曜日をお休みをいただきました。
体力のあるうちに、辛いものを食べて、熱い風呂に入って、布団にくるまり、強制的に熱を出すのが私の風邪の治し方です。一晩熱を出して、おかげで今日は熱も冷めて、鼻水の粘性も高くなって、無事回復期に入ったようです。
普段は時間があれば囲碁ばかりしていますが、思わぬ時間が空くとプログラミングがしたくなります。以前からちまちまいじっている囲碁プログラム。
思考ルーチンなしでただの碁盤プログラムですが、リファクタリングの要素が尽きません。
思うに日常の言葉の多義性と関係があるようです。普通、囲碁でこの石と言った時、石自体を示すことは滅多になくて、この一手という意味か、この石を含む、生き死にに関係する一連の石の集合（群）を意味します。群は隣接した石同士の集合である連から成るのですが、碁打ちは連という構造を構造として考えません。群の中の連を切断しようとする相手の手を考えて、切られないよう受けなければいけないか、切られたら、切断された当たらな群のどちらかもしくは両方が死にそうな群になるのか、切られても痛くもかゆくもないのか、（単に３通りではなくもっと段階があるのですが、）動的な関係として連を捉えます。静的な構造としては考えていない。手段の中で自然に演繹される構造の場合、思考を省略できるのでしょうね。思考を省略すると言葉に多義性が生まれます。
ところが、囲碁のルールや概念をプログラミングという形で説明しようとすると、トップダウンにせよボトムアップにせよ、手段と構造の明確化が必要になります。「アルゴリズム＋データ構造＝プログラム」はPascalの生みの親Wirthさんの名著（名著と書きながら中身を忘れてしまった…）で、このタイトルは、なんでもできるチューリングマシンに、させたいことを明確に指示するために方法論があることを示したものですが、実はこの方法論のある種の限界も示していると、ふと思いました。構造と手段を越えた多義性を言語的な曖昧さなく定義できたら、動的束縛を越えるようなコードの省略が可能になるかもしれません。
と、あれこれ夢想しているうちに、碁盤プログラムもかなりこなれてきました。わかっていると思っていることを論理で表現するのにこれだけ時間がかかるというのは、人間（私）がいかに論理思考が苦手かを物語っているに違いない。
全然、関係ないですが、最近、MacのDHCPクライアントがおかしいです。私だけ？