日々の破片

_ 型付けと変更に対する強さ

(時事解説)

shiroさんが召喚されたという点が、今回の発端となった(と僕は読んだけど)『変数に型がないということの利点について考える』の一番の成果だったのではないだろうか。

最初にshiroさんは、変更に対する強さというものを、平衡状態の長短として考えることを提案する(『型付けと変更の時定数』)。強い型付けであれば、非平衡状態は比較的すぐに解消する（ただし非平衡状態では実行できない）。弱い型付けであれば、非平衡状態でもそれなりに実行できる。

読んで考えた。これは実体験としてわかる。

それまでchar buff[]だったものをstd::string buffに修正する必要が仮にあったとすれば、とにかく宣言を先に変えてしまう。そしてmake cleanしてmakeし直せば、少なくとも修正しなければならない箇所はその時点ですべて網羅できる（もっとも、表面的にしか直せない場合も結構あって、おそらくそういう場合があるということは、うまいこと言語の特徴を生かしてコードを書いていないということなのだろう）。

逆にいうと、修正している時点では、その修正中のソフトウェアを実行することもできない（何しろmakeできないから）。

それに対して、すぐさまソフトウェアの出力（成果物）がぼちぼちでも必要な場合、トライ&エラーしながら成果物を作りつつ、ソフトウェア自身の拡張や修正をしていくことになる。こういう作業をしているときに、スクリプト言語は実にありがたい。だが、１か所でもテストで通っていなかったコードにタイポがあると、そこでクラッシュする（クラッシュすれば良いがnullとか空文字列とか0とかを勝手に想定してよろしくやってくれると、それはそれで異様に困るのがJavaScriptだったりPHPだったりするわけだが）。

同じくプロトタイピングと実稼働がほぼ等しい場合にHTML＋JavaScriptは実にうまく運用できる(そういうプロジェクトをやった時につくづく実感した)。

次の日になると、shiroさんは具体例を出してきた。

『システムの非平衡状態』。

Javaなプロジェクトであれば、デザインパターン（ファクトリメソッドパターンはいつでも有用だ）を適用しておけとあれほど言ったのに、な例である(もしかすると、HashMapをそのために利用しているプロジェクトもあるかも知れないが、それは別の問題を引き起こすというか、何を悪いとこどりしているのかと思うけど)。(確か以前kwatchさん（だと記憶している）が、デザインパターンが必要な言語は結局のところ欠陥言語じゃないか？ というようなことを書かれていて、そりゃそうだよなぁと同感したのを思い出すけど、それが非平衡状態が本来短い対象に向いているものの適用の失敗に対応させるための方策として考えると、確かにそれは先人の知恵として学ぶべき価値があるものだとも言える)

現在のところ、最後のエントリーが『型論争』で、なぜ、不安定な期間の許容に関する問題として提起したのかが説明されている。

jmukさんの『時定数の話をつらつらと考えていた』も併せて読みたい。

#作って検証して納めて数年変更しないシステムを、バカの1つ覚えでJavaで作るのは、平衡状態という切り口からも説明できそうだし、永遠のベータ版のサービス群がRubyやPerl（PHPも含めて良いのかな）なのも、そこから説明できるかも知れない。でも、メッセージングの部分だけはScalaを使うみたいなのも含めて。

(ご存じない方のための補足)shiroさんは、Gaucheの作者。

プログラミングGauche(Kahuaプロジェクト)

Shceme処理系の作者だからかどうかはわからないけど、LISP系言語の翻訳もある。

プログラミングClojure(Stuart Halloway)

Land of Lisp(M.D. ConradBarski)

でも、一番有名なのは、ポールグレアムの翻訳かな。

ハッカーと画家 コンピュータ時代の創造者たち(ポール グレアム)

追記(3/11)：時定数が大きく、型と直交する意味がある困難な例「古くて新しいGUI座標系の型の話」