墜落日記 - 2009年1月2日の墜落

理学と工学の差、机上の空論なぞ糞喰らえ

大腸癌の診断を下される初夢を見て鬱に入っている今日この頃。
去年に胆嚢結石の摘出手術を受けたせいか、それとも食事を自制しているところに年末年始でドガッと食べてしまったせいか、夢見が最悪である。
で、カッとなって二度寝したら今度は見たことない街で謎の組織から逃げ回っている夢―――時々反撃らしい策を弄するご丁寧なストーリ付き―――を見た。

一体どんな強迫観念に駆られてるんだ、俺(爆)

ま～年始早々に萌え萌えな夢を見なかっただけまともかもしれないが。

話変わって。
これもまた年始早々何やってるんだという話だが、拙作 Arcadian garden のサイトデザインをまたドガッと変える作業をボチボチと始めている。
ま～大体、PHP のフレームワークのプロトタイプが仕上がったタイミングで実働試験をかねて色々と使ってみて考慮漏れやバグの洗い出しをするのが主目的なのだが。
いつものことながら引っ掛かるのはフレームワークのプロトタイプの問題ではなくスタイルシートの構成なのである。
で、必ずぶち当たるのがスタイルシートによる段組の実装で―――

今までは常にスタイルシートで実現することを諦めてきた。

いくつか問題はあるが、最大の問題は float によって設定した流し込みを解除する clear 指定の効果範囲が DIV ブロックをまたいでしまうこと、画面の見た目の構造に従って文書を作成する必然性が出てしまうことに集約される。
例えば、あるフロート化された DIV 要素の中に入れ子にした DIV 要素が更にフロート化されるとする。
で、入れ子にされている DIV 要素のフロート化を解除するために入れ子の中で clear 要素を指定すると、入れ子の中だけでなくその親要素のフロートも一緒くたに解除されてしまう。
つまり、スタイルシートに於いてフロート処理はブロックの入れ子状態に関係なく常に唯一なのである。
より厳密に言うと スタイルシートから見た DIV 要素は文書の理論的な意味をブロック化するが、物理的な意味には全く無関心、ということになる。
普通に考えれば、DIV 要素でブロック化した内部で閉じたフロート空間が出来て当然で、ブロックが終了すればフロート空間は暗黙に解除されるのが構造的である。
しかしそうはなっていない。
HTML でマークアップした物理的な構造に対してスタイルシートは無力なのである。

だったら TABLE でいいじゃん、面倒くさいし、となる。

この辺り、スタイルシートをデザインした連中の理学屋的な嗜好が伺えるように思う。
HTML 3.1 で世界が滅茶苦茶になっていた頃、HTML 4.0 + CSS を定義しようとしたワーキンググループは世界のウェブページがどのような機能を望んでいるかを見ることが出来たはずだ。
しかし実際に出てきた CSS は機能的にあまりにも貧弱、それこそ単純な論文にちょこっと見た目を追加する程度の能力しか想定されていない。
（数式を記述する構文はなくなってしまったにもかかわらず、だ）

全く現実問題を見ていない。

これは理論先行、現実問題は二の次、誤差を考えないで理論値だけを出してくる理学屋の嗜好であり、とても現実問題と対峙する工学屋の嗜好ではない。
おかげで理想論では論理構造とページデザインが分離されて単純化するはずだったところが、ブラウザの実装の曖昧さとも絡んでへんなスタイルシートハックが闊歩している。
これは工学屋が理論と現実の狭間に滑り込んだ誤差を解決するために涙ぐましい努力を強いられている姿に似ている。
更にワーキンググループはこの後、XHTML なんて中途半端な物を出して現実問題に更に背を向け、今更になって HTML 5.0 なんて物を考え始めている。
自分としてはこの辺りに非常に理学と工学の差を感じるのである。

同様なことは JAVA 界隈でも感じる。
JAVA 界隈は複雑系の問題を複雑系のまま解こうとするのみならず、単純系の問題すら複雑系に取り込んで解こうとする雰囲気が感じられる。
ニュートン力学でも高校レベルの代数計算で充分な計算をわざわざ大学レベルの微分方程式で解いているというか、無駄に量子力学持ち出しているというか、そういう雰囲気である。
10 年くらい前に出てきた EJB (Enterprise JavaBeans) 仕様なんか、その最たる物ではないかな？
ま、元々 JAVA の言語仕様自体が「何も出来ない」様に作られているから仕方ないのだけど。
自分としてはこの辺りにも非常に理学と工学の差を感じるのである。

なんか理学を馬鹿にしているような論調になってしまったが、決して理学を馬鹿にしているわけではない。
ただ、「理学だけで突っ走るな」と言いたいのだ。

コンピュータの中、仮想空間でのコーディング手法なんかは理学がそのまま表に出てくることが多い。
それは製品化するために物理的な問題が絡んでくる工業製品と違い、頭の中の妄想をそのまま具現化することができるからだが、だからこそ工学的な視点が必要なのではないか？　と思う。

理論を構築したら、実際に使ってみるべきだ。
とことん使って現実問題を洗い出して、理論と現実の狭間に生まれた誤差を再評価し、理論に更に修正を加える。
それを繰り返した理論だけが標準仕様として表に出てきて良いはずで、現実問題と対峙する我々は机上の空論なぞ糞喰らえなのである。

中途半端な妄想のまま具現化された標準仕様ほど迷惑千万な物はない。