VBA

Excel VBAは究極の「変数 = 箱」モデル

某MLに書いた内容ですが、僕が遭遇したExcelVBA的なものの発想法について。
ExcelVBAでのプログラミングでは、8月8日の日記や福盛さんの日記で触れられているように、「VBAでエクセルのマクロを作る初心者がですね、変数の代わりにセルを使うんですよ」と言うような、matz日記で話題になった究極の「変数 = 箱モデル」に相当するようなコードを書く人が結構多い。
つまり、「ExcelVBAは普通のVBと違って、「手動で」かつ「視覚的に」変数領域を割り当 てられる、2次元でアドレス指定するポインタを持つBASICである。」と言い換えても良さそうですし、暴論を言えば、「一流のExcelVBA使いは1次元のポインタしかないCのポインタなど目をつぶって使えないとならない訳だ(暴論)。分からないなどと言わせぬ！」ということになる。まぁ実際に一流の(分かった気になって、有頂天になって、ナニか勘違いしている人_のことを言う)ExcelVBA使いのみなさんはこういうポインタに相当するものには名前をつけたりしなくて「全部直接セル参照」という神業をするので、構造化言語とかOOPとかにジャブ付けの頭しか持ち得ない僕なんかから見るとある意味「すげーっ！」(絶対そうなりたくない)と思ったり、頭の中がどうなっているのかかち割って見てみたいなんて思っている_3流のへっぽこVBA使い_なので、せめて妥協点として、Rangeオブジェ クトに名前をつけてアクセスしたくなっちゃいます。
1次元のRange領域を作ってやれば普通のポインタと同じような感覚(アドレス指定はCellsプロパティで2次元指定できるけど)ですかね。領域の割り当ては自分でやらないと駄目ですが… まぁ_ご利用は計画的に。
たとえば「1から10までの話を求めたい」と言う例題を考える。和を求めたいRangeオブジェクトを渡すと「Rangeの和を求めるワークシート関数を文字列として返す関数」なんてものをつくってやれば、少し楽ができそうし、応用もあるのは手を付けてはいけないと思いますねえかな? まぁ実際にこつこつアルゴリズムを書くのではなく、計算などはすでにあるExcelのワークシート関数にしまえと言うことになります。(まぁ_手抜き_とも言う) 和を求めるくらいだとあまりありがたみが出ないが、同じ手間でRangeの最大・最小とか2個のRangeオブジェクトを関数に渡して最小自乗法とかさくっと出来ちゃったりするので、まぁ楽チンですね。(実際は統計関係の計算をするときはExcelのバグを知り尽くしてないと危ないですが。まぁ統計をちゃんとしたい時はExcelは使っちゃいけません。ちゃんと統計ソフトを使いましょう。)
ということでコード例。(基本的にVBでプログラムを書くときは型宣言を必須にしましょう。そうでないと全部Variantになったりしますから。あとDim文の使い方も意図しない型宣言になったりしますので注意しましょう。)

今日は1日中Wordで文書書き

期末も近いのでたらたら報告書書き。ということで、しばらく使ってなかったWordの使い方などを再構成中。まぁWordはシステマティックに使っていたので、何年も使っていなくても人が知らない機能はサクサク出てくるんですが、メニューの配置がだいぶん変わっていてかなり手間取る。僕が使い込んでいたのはWord1.2とWord6.0までで、そのあとは文書書きはLaTeX。会社に入ってからはExcelで文書書きを強制されていたので会社ではExcel、家ではテキストしか用事がないからEmacsで編集というスタイルに落ち着いているわけだが…
数時間格闘して、とりあえず図表番号の付け方、クロスリファレンスの張り方を思い出す。あとはがんがん書くだけだ。ただある程度書いて報告書形式のスタイルを適用しようと思ったら… 全然インストールされてないじゃん！ せめて基本的なスタイル集・オブジェクト編集ツール(数式エディタとかExcelの何個かのアドイン)・VBAのヘルプがインストールされていないと、まるでお仕事にならないんですけど！
まぁUnix系な人やWordを全然使いこなしていない人には、MS-WordがEmacsの次に好きな文書書きツールであるって言うと、_気でも狂ったんじゃないの?_とか言われそうだが、使い勝手の良いアウトライン・エディタって、身近にあるのはEmacsとWordしかない。まぁ僕は基本的にはアウトラインモードで項目をメモ状に書いて、前後関係を考えて、おおざっぱな文書構造を書き連ねて、詳細な段落を書くという非常にトップダウンな文章の書き方をするので、アウトラインエディタが必要なんです。

Lightweight Language Weekend 2日目

2日目の前半は最近はやりのblogな話題。僕は基本的に興味がないのだが一応お勉強のため… 大きなblogサイト(Livedoor Blog)やはてなダイアリーなど)の方が来ていたので、個人的には「(政府や各種圧力団体などから圧力がかかりそうな)非常にまずい記事の削除要請があった場合にどのように考えるかの立ち位置」を効きたかったのだが、LLには関係ないし、契約で乗り切れる話かもしれないし、あまりにダークなんで聞けなかった。聞いておけば良かったかな？ LLの最も巨大な応用先であることは認めるが、blogだけでこんなに時間を取るんだったら他の話が聞きたかった。
Lightning Talkは詳細はあまり覚えてない。(なんせ半分くらいBitKeeperと話をしていたので。) 平内さんの「木のマッチ」では、Schemeを使用した木構造のデータに対して正規表現みたいなパターンマッチをする話。さくっとXML VallidatorがかけるあたりがSchemeのマクロらしい。久井さんの「Gauche-glによる、3次元図形言語」では、Gauche-GLとストリーム(SICP Chap3の後半)を使ったアニメーションによるプレゼンでGaucheではこんなこともできるのかと言うこともあってこれまた面白かった。
高橋さんの「日本Rubyの会設立」の話は要点とをついたインパクトのあるプレゼンで、こうあるべきかと思ったり… 早川さんの「LL侍」は最初は照れが見えたが、吹っ切れたあとはかなり面白かった。(もう一段切れが欲しかったかな。)

GNUの20年

ずいぶん前の話になるが、昨年はrmsがGNU Projectへの呼びかけ(翻訳,後の「GNU宣言」の元になる文書だと思う)から20年目の年だったそうな。昨年の9月末の話なので何をいまさらという話であるが、1月5日のNewsforgeにrms自身による「The Free Software Community After 20 Years: With great but incomplete success, what now?」という記事(和訳)が掲載されていたので、読んでみて思い出したかのように日記の記事にすることにした。
ソフトウェアにそれなりに踏み込んでつきあうようになると誰でもそうであると思うが、GNUの成果物の恩恵に預かっていることに気づかされることが多い。僕の場合は今年で11年目になると思う。最初の出会いはテキスト処理をするために使い始めたawkであるが、MS-DOSで使っていたので当然GNU版のawkであるgawk(の日本語版jgawk)だったように思う。当時書くのもめんどくさいテキストファイルのフィルタ処理がこんな簡単な言語でできるもんだと感動して使った記憶がある。(その後、awkの使いこなしでは師匠に絶対勝てねえと思ってperlを使うようになりawkを忘れ、今はテキストの処理の需要があまりないのでなんにもやってないが。)
その後、数値計算でCでプログラムを書く機会が多かった(Fortran嫌いなんで)ので、MS-DOSでMS QuickCを使っていた。Cを始めた頃はこの処理系でよかったが、当時積分計算をすることが結構多くて処理速度を稼ぐために最適化をかけたいことがよくあった。ただMS-Cのような処理系は_学生時代には絶対買えないお値段の処理系_(今も買えませんが)で、とても手を出せる状態にはなかった。またMS-DOSの制約以上の大きなメモリ空間を計算上必要としていたこと(こっちの方がより重大だった)ため、どうしてもMSのツールじゃ駄目だった。そんなときに大学のFTPサーバを覗いていて発見したのが、GNUのCコンパイラGCCのMS-DOS版であるdjgppでした。DOS-Extenderという妙な環境で動く何ともしれないコンパイラだったが、結構長い間愛用していた。
その後のLinuxの登場によりMS-DOSという妙な環境ではなく、何の制約もないUnix互換環境でGCCを使えるようになったので、ソースファイルごとLinuxの環境に移行してしまい、それ以来何かツールを作る環境はLinuxの上でやってきているし、こんな素晴らしいものはないと言うことでLinuxや*BSDの普及活動に時間があったら手間を惜しまず関わっている。まぁ最近はC/C++でプログラムを書くこともなくなったので、すっかり一利用者になってしまったけども。(お仕事上のVBAは除く。あれは選べない環境なので。)
最近の風潮ではGNUのGPLによる配付の縛りがきつすぎて、_GPL嫌い_な人を結構見かけるが、近年のオープンソースムーブメントのよりどころは_Linusによるバザール的開発手法の発明_とESRによる精緻な再定義によるものだとかんがえられる。しかし実際にはそれ以前の_rmsのFree Softwareの運動が基礎として存在_しており、GNU嫌いな人も_アンチテーゼとしての存在としてのGNU_なしには語れない訳だから、すべてに対して影響を及ぼしていると考えて良いと思う。改めて凄いことだと言わざる得ない。
さて、最初のrms自身の記事にもどるが、ちょっと過激なところはあると思うが大いに刺激を感じる記事かと思う。たしかに僕自身も特許やら企業秘密の中に生活している人なので、特許や企業秘密に依存するソフトウェアがどうしてもclosedでものでproprietaryな物にならざる得ないのは理解できるので、「Non-free software carries with it an antisocial system that prohibits cooperation and community.」は、ちょっと言いすぎだろうと思うが、先鋭的な意見を述べて戦い続けなければならない立場を考えると、確かにそう言い切ってしまわねばならないのだと思う。
さらに読んでいくと、

.NETの呼び声

最近、VBAでのプログラムにほとほと嫌気がさしてきたのであるが、お仕事関係ではMicrosoft WindowsというかMicrosoft Officeの呪縛を逃れることは出来ない。それ故プログラム環境としてVisual Basic for Application(VBA)を使うことになるのであるが、不満は多いので使っていてなんだかだめだめだなぁと思うことを列挙してみよう。

• _必ずExcelやWord文書の付録_みたいなものになる。文書を開くときに何となく厭な気分になる。(回避法はあるけれど。)
• 当然コードの_履歴管理をするのが大変_。(何が楽しくてVisual Source Safeを使わねばならないのか。頼むからCVSやSubversionを使わせてくださいな。)
• 正規表現が使えない。(がーん。 かなり不便。)
• 正規表現を差し引いてもテキスト処理がいまいち。(変形CVSなテキストを読むのがもう大変。)
• しょっちゅう関数の名前がだぶる。(名前空間をサポートしてくださいよ。僕のボキャブラリが寂しいだけ?)
• 使えるデータ型が_恐ろしいくらい貧弱_。(未だに基本な型と構造体と配列くらいしかなく、ハッシュやリストのような現代的な言語でサポートされているデータ型は_当然ない_。)
• クラスは作れるが、継承は出来ない。(勘違いしている人は多いけれど継承はOOPの必須事項ではない。)
• スレッドって何だっけ?
  という具合で、結構痛いところが満載なのである。そこまで使い込んでいるんだったらVisual Source Safeというか、OfficeのDeveloper Editionを買えばいいじゃんと言う意見もあろうが、僕はお仕事のためにわざわざOffice Developer版を買うほど酔狂な人間ではありません。 ちなみに家のPCにはOfficeをインストールしてません。家に帰って_Excelのアイコンを見るのも厭です_。ということで、会社で買ってくれないものを使う気にはならんのです。
  かといって、Windows Scriptの上で動く現代的なスクリプト言語であるActivePerlやActiveRubyは、_デフォルトでインストールされない_ということもあって、プログラムを使ってもらうという前提の開発では、管理が発生するためにメインの言語として選べない。(ExcelはどのPCでもバージョンは同じであることを前提に出来るが、PerlやRubyのバージョンなどの管理は職場で誰がするの?)
  ひょっとしたらVBA自身は、Office2003でVB.netのような言語の現代化が行われるのではないかと多少期待したのだけど、VBA自身はVBA 6.3から6.4にアップデートで余り変化はないみたい。(がっかり。 まぁ無論会社ではOffice2000までしか使ったら駄目ということになっているので、Office2003は使えないのだが。)
  という状況で、なんだか良い解法は無いなぁと思っていたのだが、先日のTCP/IP勉強会で、PostgreSQL方面の高橋さんより、「そういう話なら、.NETが良いよ。」という話を聞いたので、早速試すことにした。
  よく.NETのページを眺めていると、.NET Framework SDKには、コマンドライン版のC++とC#とVBのコンパイラが付属してくるのね！ てっきり、C#やVB.netで遊ぶにはVisual Studio .NETを買わねばならないのかと思っていたのであるが、僕が組むプログラムの規模ではVisual Studioには手を出さなくてよさそう。
  ダウンロード・インストールをしている間にWebをさまよえば、_フリーの統合環境は転がっている_もので、Javaの開発環境から進化して、C++やC#やPerlやRubyやXMLなどの編集が行えるJavaで書かれているEclipse(エクリプス)や、C#の開発環境に特化しつつVBの開発環境にも使えそうなC#で書かれているSharpDevelop(SharpDevelop-JP)といったオープンソースな環境が出回っているので、なんだか簡便な開発環境が整いそうである。
  今日はつらつら.NETのドキュメントとC#やVBのサンプルソースを眺めているわけだが、眺めているだけでも上記の問題は解決しそうである。例えば順に並べるとこんな感じ。
• ソースコードは_ただのテキストファイルになる_(当然)
• 当然コードの管理にCVSやSubversionを使える。
• Microsoft .NET Framework ではPerl5のような正規表現がサポートされている。
• テキスト処理はようわからんが、コンソールアプリを書けるからたぶん大丈夫でしょう。(調査中)
• 名前空間をサポートしている。(僕のボキャブラリが寂しくても_安心だ_。)
• コレクションクラスが_充実している_。(ハッシュもリストも_当然ありますよ_。)
• VBでも継承ができるようになった。(VB7からは継承が出来るようになりました。)
• スレッドを考慮したプログラムも当然書ける。
  という具合。ガベージコレクションもしてくれるのですか。メモリ管理関係も結構楽になるのかしら… しばらく眺めて勉強してみることにするが、MSと仲良く付き合うには、_過度の期待はしない_ことと_仕様はどうせすぐに変わるもの_と思って、_適当に勉強すること_と言うのが重用である。どうせ勉強しても長く持たないバッドノウハウだらけになるに決まっているのだから。
  今日の日記はリンクをいっぱい付けてみた。疲れたなぁ。