VBA

今日はお休み

ようやくお休みになった。なんだか風邪を引いた模様。のどが痛い…

VBAを使う理由

昨日の議論の続き。じゃ_なぜにVBAを使っているのですか?_と言う話も言及しておこう。
本来VBAでできるものは、Active PerlやActiveScriptRubyで書いた方がよりスマートにかける。こないだも苦労したが、VBAは文字列処理が非常に弱いので、テキスト処理を得意としている言語でやった方がスマートにかけるプログラムは多い。
じゃなぜ?と言う話は簡単で、VBAで書く物はお仕事でしか存在しないからだ。(僕は家のPC用にOffice2000のライセンスを2個持っていますが、インストールしてません。) ただみなさんに「ActiveScriptRubyをインストールしてくださいね」と言うのと、インストールしてもらう利点を説明するのが、めんどくさいからだ。(だってExcelはすでにインストールされているものね。)
ただ最近ExcelのシートにマクロをつけるよりはAddinとして配布すべきだと思い至ったので、最近僕が作るマクロはAddinになるようにしています。使っている理由はただそれだけです。VBやVBAというかMSの生成物に美しさを期待するのは愚の骨頂なので、適当におつきあい。それが正しい姿であろうと思うのだ。書きたい言語で書いていいよと言われれば、絶対選択しない物であるのは確か。

やっぱりVBAは嫌い

今日はなにげにVBAでテキスト処理プログラムを書いてみた。汎用なカンマ区切りテキスト処理を行いたいのだが、ちょっと変なファイルで、最初の項目だけコロンで区切れられているファイルで、レコード長は最初の項目で決まるので、普通のストリーム入出力なら、

• 一行読み込み
• 受け用の配列に取り込み(Cで言えば sscanfとかを使うのね)
• 内容に応じて、適当に逐次データ処理
  となりそうなものだが、そうはいかないところがVBAの凄いところ。こういう処理をする関数やステートメントが存在しないのよ。おそらく可変数の変数をもらう関数が書けないせいだと思うが、配列使えよって言う感じ。さらに連想配列がないのもつらいねぇ。(Excel VBAの場合、シート上にデータをおいた方が早かったり。何か違う気がする。) 結局、
• 一行読み込み
• 行の頭から1文字ずつ読み込んで、区切り記号が出て来たところで、前の区切り記号からの文字を配列に取り込み
• 行の末尾まで繰り返し
  というなかなか楽しい処理を行う羽目に。何と素晴らしい。なぜにここまで低レベルの処理を書かないとならないんだか。さすがMS。苦労したおかげで、何とか思い通りの処理を書けそう。
  もうテキスト処理が得意な言語で書けば良いじゃんと言う話があるんだが、最終的な出力はExcel文書でrubyにしてもperlにしても、新たに処理系をインストールしてもらわないとならないので、できない状況なのよね。もっと便利にならないものかね。もっと良い方法があったりして…

図ったように雨ですねぇ

GWは気持ちのよい天気が続いたが、終わったとたんに雨が降るとは、なかなか便利な天気だ。世の中のおとーさま達もさぞやうらめしいことだろう。とはいえ、日曜日と月曜日は晴れてよかったですねぇ。

VBAにおけるストリーム入出力

Cにおける以下のソースと等価なVBでの表現はどうなるのだろう？ 誰か知っている人、教えてください。お分かりのように、scanfを使うなと言う話なんだけども、1行入力してからデータを切り分けたい時ってあるんだよね。

(void)fgets(line, sizeof(line), stdin);(void)sscanf(line, format, &var1;, &var2;, ... );

思うに、VBAでsscanfのような事って出来るんかいな？

Java World 2002.06

JDK 1.4が付属すると言うことで購入した。JDK1.4のレビューも掲載されていたのでこれはよいと思って買ったのであるが、JDKの今回のリリースの見所はXML関係のライブラリ充実(JXAPの追加)と言うところか。JAXPをダウンロードせねばなぁと思っていただけに結構嬉しい。あと最近の興味で遊べそうなのはImage I/O APIでしょうか。
C++のtemplateに相当するJava Genericsの搭載はJDK 1.5に延びたらしいので、まだまだキャストの呪縛からは逃れられないのは残念。僕はC++が大好きな人ではなくなったけど、膨大なC++の余計な(笑)機能のうち、templateは珍しく評価している機能なだけに、Javaにまだ存在していないのは痛い。もっともtemplateを評価しているのはSTLの存在によるところが大きいのであるが。評価Java Genericsを使用したSTLみたいなライブラリが登場すると、非常に魅力なのだけどねぇ。

またまたVBAと戦う

この間とは違うマクロの改良を行うべく、またまたVBAと戦うことになった。今回は表示周りに手をかけずにロジックを付け足すというものであったから、結構簡単にいった。それでも表示部分をもっと再利用性のよいライブラリになるようなものにしておかないと、またまた保守できない・する気にならない状態になってしまう(すでに中身を変更する気はないけども)ので、もう少し時間をかけていじっていこうと思う。業務に必要なだけに困ったものだ。(そもそもExcelに依存していることが問題なのね。)

全然もたない

昨日の記事の続き。全然もたないので、ちゃんと寝ることにする。8時間くらい寝れば回復するだろうか。

VBAだめすぎ

別にVBAやVBに限った話じゃないけど、簡単に汚いソースを書けるのはだめじゃな。(昔はPerlもそうだったけど、今使ってないからいいや。) 行き当たりばったりの使い捨てマクロなら書けるけど、何年も保守するようなプログラムの場合はちゃんとした設計をしないと保守性をあげられないな。今回いやになってしまったのは、結果出力周り。付け足したいロジックを表示部に埋め込まないとならなくて、もういやになってしまった。昔の人はDoc-Viewとか格好いいことを言って、ロジックとプレゼンテーションを分離しなさいと言っている訳だが、ごもっともって思い知りました。
最近はVBAでも気をつけて書いているので、最近書いているマクロは読めるんだけどね。Excelのオブジェクトの階層構造とメソッド・プロパティが分からないので、ずるしてマクロの記録を使うのが問題のようだ。たしかに、1からソースを書くときは綺麗に書けるものね。
と言うことで、Excelで遊ぶときはActive Ruby、そうでないときはJavaで環境を統一したいなぁ。やっぱり綺麗に書く努力をしたくなる言語を選択すべきだな。それ以前にVBAのようにオブジェクト指向言語のような感じで実はまがい物というものを使っている時点で問題なのかも知れない。

VBA

久しぶりに2年前に書いたVBAのソースを眺めた。プログラミングの世界では、「昨日の自分はもはや他人」なので、さすがぱっと読んだだけでは中身が良く分からなかったが、デバッガでトレースしていたらどういう処理をしてどう考えていたか思い出した。ということで所望の変更は行えたのであるが、問題はそれ以前にあって、やっぱりVBAのコードが好きになれない。というかBASICが好きではないんですな。
僕もBASICで育った世代で、最初に使ったプログラム言語は小学生のころでN66−BASICだし、そのあとはずいぶん飛んで大学時代の前半はN88-BASIC(86)でフラクタル図形を書いて遊んでいた。ただこの手の繰り返し計算モノでBASICを使うのはナンセンスなので、そこでC言語に切り替えてしまったクチであるが、その後もMSの術中にはまってQuick BasicだのVisual Basicだの表題のVBAなんかも使っているわけだ。構造化されたあとのDOSベースのQuick Basicはそこそこ出来た処理系だったと思うが、その後のものは悪ノリで作っているとしか思えないシロモノだ。そう思うのは、VBはWindowsのバージョンにかなり依存した言語設計になっているし、VBAはさらにOfficeのバージョンによってかなりコーディングの変更を強要するからだ。僕は1年やそこらで言語以外の要因で仕様がころころ変わる処理系に付き合いきれない。普通そうだろう。
と言うことで、最近は小物のものはRuby、遊びとXMLモノではJavaで遊んでいる。Emacsを使うためにLISPを使っていることも忘れていないが最近あまりコードを書いていない。LISPみたいな関数型の言語はコーディングの発想がぜんぜん違うのでなかなか取っ掛かり難いが、こう言うものをたまに使わないと人間として駄目になってしまいそうだ。そういえばEmacs Lispで遊んだことで、Mathematicaのマクロをすぐに使えるようになったことがある。Mathematicaのマクロは文法こそC-likeな言語であるが、基本的にはLISTをいじる事が多いので、LISPが分かると簡単にLISP風なプログラムがかけて強力に使いこなせる。面白い体験だった。やっぱいろいろな言語を使うことは重要だのう。