日々の破片

_ ツールプログラミング

2〜3日ほど、HTA+ASR+Excelでツールをえんえんと作っていたのだが、最後の最後でHTA終了時にExcelがクラッシュする。

（中途半端にクラッシュするから、OKをクリックだとゾンビ化してしまうので、キャンセルをクリックして、でもデバッガを起動しないで完全に殺す）

これは不思議だな。

ASR（Win32OLEも）は、RubyのオブジェクトとしてCOMのインターフェイスを保持するから、完全には参照カウンターのゼロ化はできない。GCがかかればいけるけど。でも、Excelの場合、これがとてつもなく厄介なことになる。

たとえば、コレクション.レンジ.レンジ.メソッドのような呼び出しが結構出てくるけど、間に入ったレンジオブジェクトをスクリプトからは直接触れない（Win32OLEには参照カウンターをデクリメントするための最終兵器が用意されているから、オブジェクトさえあればどうにかなる）ので、結局GC頼みとなる(Win32OLEというかASRはRubyのオブジェクトを生成しているけど実際には参照をスクリプトが保持していないということまではわからない)。で、HTAがさっさと終了してしまうと参照カウンタが残っているのでプロクシとスタブの両方が生きた状態のままとなっているからまずいはまずいのだろうが、でもなぜ終了した瞬間にExcelがクラッシュするんだろう？

でもツールだし、とりあえず見るのは面倒だからいいや、と気にしないで使ったりしているのだが、でもクリックするのは逆に面倒だし、ゾンビがどかどかたまるのも嫌だ。

でもまじめにデバッグするほうがむしろ面倒だからいいや、とループしたり。2000/2000の組み合わせ固有の問題だといいな、と思ったり。

というか、こういう時は参照カウンターは厄介であるな。JNIのDeleteLocalRefも同じようなことなんだろうか。

_ ワインバーグはただのバーグじゃないみたいだ

スピルバーグもただのバーグじゃないが、さらにすげぇや。イーグル村通信を読んでた頃はあまりわからなかった。でも、ワインバーグが15年間のプログラマ、プログラムの指導とかの果てに書いたこの本を今読むと良くわかる。それもすごく。イーグル村の頃は僕には早すぎたのかも知れない。

というわけで『プログラミングの心理学』の25周年版をつい手にとったのが運の尽きで読みふける。

手にとって最初に目に止まったのは次の1節。

わかりにくいところをはっきりさせる、という仕事をコンピュータ自身に委ねている。

そう言えば、ちゃんと読んだこたなかったな、と気付いて買ってみた。

しかし、厚いので全体をぱらぱら見た後に細かく読んでみたり。

ああ、当時こんなものがあったら、どんなすごいことがやれただろう! ううむ、実は当時やったと同じことをやったんじゃないかなあ。そう、本物のプロなら誰でもやるようなことを。つまり、もっとたくさんの道具を作る、ということを。

でも、第4部を読んで少し悲しくなる。

だが私は、メタ言語をはじめとする各種の道具類を利用してコンパイラを補完する、という話には大いに興味を持っていた。

MDLとかDSLとか。

全体としては、この実験はうまくいかなかった。（中略）すぐれた道具は、劣った言語の寿命を引き伸ばす役しかしないのだ。

劣った言語っていうのはなんだろう？

でも、変わらないことの最たるものは

自分のプログラムを審美的対象として眺めてみる、ということをたまにはしてみないプログラマは、真のプログラマとはいえないだろう。

ということじゃなかろうか。

それが審美的対象であるということは、谷川俊太郎が好みの人もいればサンボリズムが好きな人も、俳句が好きな人も、でもバイロンは嫌いとか、ボードレールは鼻持ちならないとか、好みがいろいろということだ。ところが、プログラムに対してコーディングルール(特にスタイル)というものを設けるという発想は、審美的対象を一方的に押し付ける試みである。そんなのは学校でやればよいことだ。今日は俳句の授業なのでみんな5-7-5で書いてください。5-7-5で書けたかどうかはcheckstyleが判定してくれます。バッカじゃなかろうか。スタイルを強制してどうするよ？

（追記：そうだ。僕は書く人のほうが読む人より常に偉いということを自明の前提としている。だから、Emacsがあの恐るべきGNUスタイルで書いてあっても読むし、K&Rも普通に読むし、MFCのソースがハンガリアン記法を駆使したMS流儀でももちろん読むし、UCCだろうがLCCだろうが_結合だろうが当然のように正しく読める――ただしオブスキュアスタイルは話が別だけど。中原中也も読めれば萩原朔太郎も読める、それだけのことだ。ところがこの重要な価値原則がコペルニクスよりもっと大胆不敵に転倒している人達がいるということは、恐ろしいことだ。）

ここで「育てる」とは、彼らに何らかの「最良」の思考形式を強制することではない。（中略）プログラマにほかの人の思考スタイルに沿って考えることを強制すれば、必ずそのプログラマの問題解決能力を削ぐことになるのだ。だから最大の挑戦は創造的思考にあるのではなく、創造的コミュニケーションある。つまりわれわれの考えを、それぞれ独自のスタイルを持ったほかの人々に理解可能なように表現する、ということが重要なのだ。

ってことは、仮にもプロフェッショナルな仕事をする場が学校なのか？ という疑問さえ湧いてくる。というか、確かに韻も踏めないような連中がプログラムを書いていたりするわけな状況ってのは確かにあるのだが。つまり「真の」ってのが問題だな。教育されていない人間が実際に使われるシステムを作ってたりするってのはなんなんだろう？ (追記：学校というよりはやはり徒弟という感じだな。それはそうで僕もそうだった時期があるわけだし、と思い返してみる。っていうか今でも学ぶことは多いわけだし。むしろ、1番下に合わせるという手法と、教育をきちんと弟子として扱うのではなく取りあえず前線に送っちまえ――軍隊ですら最前線に送る前に教育があるわけだが――という手法の問題だろう)

プログラムの審美的価値と実用的価値に相間があるのは、決して偶然ではない。目や心に快いものは、正しいという可能性が高いのである。

（もちろん、読む側に立ってのことではない。書く側に立っての「審美的価値」のことだ）

BTW、狂った爆撃機に陥る可能性について常に注意を払う必要がある、ということは重要だ。他山の石にしよう。

追記：アプソリュートモン、アブソリュートメント、読みが異なるのは語尾だけではない。

_ 車輪の謎

突然、わかった。「オレが発明した」車輪は2度と発明しない、が正解だ。「オマエが発明した」車輪は「オレがもっとうまく」実装する。

注）これは「心構え」であって、「技能」がより重要なのは自明である。

_ ハック、ハッカー、ハッキング

最強ハッカーを探せ。

読ませるね。いったい誰がこんなにわかって書いてるんだろうと思ったらma2さんだった。でも惜しむらくはちょっとタイミングが早かったせいか、big fool man以来の最強ハッカーbitchcheckerが出てこないことだな(もちろん彼についての本は永遠に出ることはないだろうけど、言及くらいは欲しいね。話題性に関しては2005年のナンバー1ハッカーのはずだ。追記：原文を読むと実は――と棒読み――bitchcheckerはすべてをお見通しで帯域の消費をたくらんでいるんだ。なぜならば、最初からbitchcheckerはlolと叫んでいるではないか。lolから右端のlを削除して語が持つ対称性を崩す。そうloだ。それにしてもDSTとhackをgoogleに適用するとその破壊力と浸透力が見える)。

紹介している本に闇のダンテとかケビンの身と肉みたいなソーシャル系の連中が出てこないところもいいな。

悪魔のパスワード (講談社文庫)(脇 英世)

ちなみにろくでもない本だが（いろいろ工夫はしているんだけどね）、1985年という早い時期に書かれたということでは脇英世の悪魔のパスワードについても触れて欲しかったかも。妻がなぜかハードカバーで（ということは出版されてせいぜい2年くらいということだ）買って途中で投げたので代わりに読んだのだが、いっぱい脚注を入れて（何となくクリスタルみたいだ）しかもその中にいろいろ言い訳が書いてあって、しかもすべて外していて妙にうら悲しい本であった。

_ 新しきものは古くなり古いものが新しくなる

Unix型プログラマとメインフレーム型プログラマという2分法を考えてみる。

そんなことを最初に思ったのは、中村正三郎がIBMのオフコンのファイルシステムを絶賛したのに対してBSDハッカーから集中砲火を食らったのを目撃したときだ。

僕はその時、BSDハッカー側がどうも中村正三郎の書いた内容を正しく読み取ってないように思った。

とは言ったって（しかしなんて名前のオフコンか忘れたけど）を実際には知らないからそこは想像でしかないんだけど、PL/IかCOBOLかどっちを使うにしろ、そこではプログラマはファイルシステムをまったく意識しないでコードを書くんだろうな、という見当がつくからだ。ネットワークファイルシステムデータベース（以降、全部こいつの間違い。NFSじゃないんだからまったく）を利用してレコードを単にたどっていくだけなのだろうということだ。それは僕が使ったことがあるファイルシステムを強く意識しなければならない環境でのCOBOLのプログラムからの想像なのだが。

もちろん、推測だから間違っている可能性はあるんだけどこんな感じになるんじゃなかろうか。

def Foo : ここにファイルマッピングに関するメタデータかまたはJCL上のメタデータとのリンクが記述される
  attr_accessor :bar, :baz, :key, :content
  def Foo.root  #単なる宣言
  end
end
a = Foo.root    #aはディスクから読まれる
a.content = "a" #"a"はディスクに書き込まれる
b = a.bar       #bはディスクから読まれる
b.blabla = 384  #384はディスクに書き込まれる

でも、メモリーマップトファイルの場合、プログラマがマッピングを意識する必要は確実にある。無いライブラリを作るという手段もあるかも知れないけど。ネットワークデータベースみたいにはうまく整理してくれるとも思えない。もちろんファイルシステムを作ればよいのだけど。でもそんなものはいらないだろう。というところからファイルシステムがファイルのスキーマを持つシステムと持ちたくないシステムの差というのが正確かも知れない。(追記：これ、ぶれている。多分実際にはスキーマをプログラムで決めていないと想像できる点は重要なんだけど、そういうことは論点じゃなくて、あくまでもディスク上のファイルシステムと主メモリがシームレスという点が論点だったように思い出してきた。とすれば、中村正三郎が的を外しているんだけど、でもおそらく感じたであろう点ははプログラムではなくストレージが自分を知っているという点だったんじゃないかなと思う。)

その結果、片方は（ファイルシステムがスキーマを持つために）プログラムの中での表現について語れるからそうしているのに、片方はシステムの機能について語っているように見えたということだ。

つまり、stdio.hやio.hが存在しない世界のプログラムをここではメインフレーム型プログラムと呼び、明示的なopen（別にio.hの必要はなくてIO.openでいいんだけど）がある世界をUnix型プログラムと呼んでいるだけのことだ。

多分、メインフレーム型プログラムの世界は死滅したんじゃないかな、と思っていた。もちろんメインフーレムとその文化圏じゃ生きてるだろうけど。

ということと、以前から不思議に思っていた、なんでそんなにO/Rマッピングしたがるんだろう？ 直接SQL書いたほうが効率も良いし、記述も明確だし、まったく理解できないなぁ、多分、ResultSetが常にSQLExceptionとか投げてかったるいし、テーブルスキーマを抽象データ型とみなした場合の型安全性の問題なのかな（ResultSetから取り出す場合は綴りミスがあり得るカラム名指定か、番号ずれがあり得るインデックス指定しかできない）と漠然と思っていたことが、そういう実利的、実装技術的なことではなくメインフレーム方プログラムという思想と同根じゃないかな、と思い当たった。ちなみにインピーダンスミスマッチという言葉を理解しているかどうかはこの場合関係ない。

『プログラミングの心理学』の制約に関するところを読んでいてのことだ。

メインフレーム型プログラムの発想からいけば、自分(ではなく、プログラマということだ)でIOを制御する（たってSQLであって制御してんのはRDBMSなわけだけど）なんて、とんでもない、ってことなのか。だからJDBCを直接使わせないようにするにはどうしたこうしたみたいな話になんのかな。するとOODBMSというのもそっち系統の発想なのかも知れないな。っていうかネットワークファイルシステムと同じように見えるし。

CMPってのも考えてみたら、そういう仕組みだ。配備記述子は（発想としては）開発者が記述するのではなく配備者という名の運用者が記述する。JCLでのユニットアサインやファイルマッピングと同じことだったのか（と思い当たってすごく納得する）。どうりで、嫌われるはずだ、まともな開発者からは。

でも、それほど利用されていないらしき状況から想像すると、多くの開発者はそれでもUnix型プログラムにまだ近い場所にいるのかも知れないのかな、と考えてから、いやそうでもあるまい、きっとUnix型プログラムのリテラシが今現在では意思決定のヘゲモニーを握ってる傾向があるってことなんじゃないかな、とも思う。

しかし、さっさと自動化できるところは自動化しちまうべきだな、と強く思うのだが(そうすりゃ、書き方教室みたいな話は機械にやらせりゃいわけだし)、まだ4半世紀か。言葉の発明から文字の発明まで人類がどれくらい時間をかけたかを想像すると、当分は無理かも知れないな。