 |
ＶＢが好きになれない訳 |
| ★ こんなタイトルの文章を書いて良いものだろうか。？ ＶＢユーザに怒られそうだけど... でも、あえて私の勝手な解釈を書きます。 ★ ＶＢは、最初に見たときはＷｉｎｄｏｗｓ3.1の環境で、Ｗｉｎｄｏｗｓ環境にて扱いやすそうな印象は受けました。 それ以前は、Ｗｉｎｄｏｗｓ上で動く開発環境はまだ限られていて、会社にあったのはデータベースアプリ開発専用のＳＱＬ Windowsでした。 これは、グラフィカルなプログラムを作ったりするような汎用的な言語ではないため個人的にはあまり興味がありませんでした。 ＶＢは、扱いやすそうではあったのですが Windows3.1のＶＢは インタプリタで速度の面でいまいちという感じでした。 それは、ＤＯＳの時代にインタプリタは遅いもの、特にプログラムが大きくなるほど遅さが目に見えて現れてくるのを体感していたからでした。 Ｃプログラムの切れの良さを知っているプログラマにとっては、魅力半減というところでしょうか。？ それと、DOSの BASICではあったものが ＶＢではなくなっているのに気がつきました。 それは、INPと OUT、PEEKと POKEです。 どれもハードウェア資源に直接アクセスするステートメントです。 Windowsになった事により、ハードを直接制御させない仕様になってきてるんだなと思いました。 私は、DOSで計測制御のアプリを何度か作成してきているので、IN、OUT命令がどうなっているんだろう。？ ということが気になったのです。 例えば、パソコンに A/Dコンバータを搭載してもWindows上のアプリからはアクセス出来ないじゃないか。？ と思ったのです。 ★ もう一つ、ＶＢにいまいち興味を持たなかったのは、言語がBASICで、言語仕様的に古い。 プログラムの流れ制御に、GoTo文を用いていること。 continueや breakが無い。 ループ処理から脱出する際に breakが使えないのは辛い。 ループの後ろにラベルを置いてgoto文で脱出しなければならない。（それじゃアセンブラと変わらんという意見もあった。） その他、スコープ性を意識したＣ言語のような構造化プログラミングは... 考えないほうがいいでしょう。？ その後バージョンアップの都度、徐々に付け足したような形で機能拡張が行われ、インタプリタでなくて実行形式も作成出来るようになりました。 基本的な言語仕様はあまり変わっていませんが、そういう面では改良がなされました。 しかし、私が好きになれないのは、オブジェクトモジュールの中に必ずメイン関数が含まれる事。 というより、ソースファイルからいきなり実行形式ファイルが出来るので、リロケータブルなオブジェクトファイルが作成できない。 これは、何を意味するかというと、Ｃ言語のようなライブラリモジュールを根本的にＶＢでは作成できない。 ということ。 これは、完成してソースを隠蔽したライブラリと、開発中のモジュールをリンクするという開発スタイルがとれない事。 この事により、ＶＢでの大規模アプリ作成は難しいのではないかと思います。 ＶＢでは、コントロールというビジュアルな部品をフォームに張りつけるという新しいWindowsプログラミングを提供しました。 これは、画期的な事です。 いわば、ビジュアルなライブラリです。 しかし、コントロールという部品は、ＶＢユーザにとっては提供されるものであって自分で作るものではありませんでした。 初期の段階ではコントロールは ＶＣ++？ でないと作れないという事でした。 マイクロソフトとしては、一般プログラマーにはＶＢ，専門のシステムプログラマーはＶＣ＋＋という２極化の方向になるという考えのようでした。 その後、バージョンアップを重ねコントロールもＶＢで作れるようになったようです。 ★ しかし、ＶＢのコントロールは最初は VBXという規格、次は OCXという規格、次は Active-Xという規格と互換性を犠牲にしながら変貌を遂げます。 昔の16bitのＶＢ２を ＶＢ６に置きかえる仕事がありましたが、間にＶＢ４を中継に入れてソースを変換して行きましたが、一部のコントロールがうまく置き換わってくれません。 それと、VB2（16bit）のソースを VB4(32bit)に移行する際に、文字列の内部表現の仕様が UniCodeに変わっているのです。 ユーザ定義型に固定長文字列データが含まれていて LSet等で、文字列バッファに代入処理を行ったりするコーディングがあると文字列データはおかしなことになります。 当然、ASCIIコードが入っているつもりで MidBなどで部分文字列を取出すコーディングもおかしな事になります。 この文字列処理の置き換えには大変苦労しました。 ★ それと、プログラムを作ることが本職ではない人のＶＢプログラムをＣに置きかえる仕事をしましたが、これも難儀しました。 まず、ソースファイルが、８千行とか、やたら長いのです。 そして変数を型宣言しないでいきなり使ってあるのです。 Delphiでは、考えられない事ですがＶＢではそれが許されます。 変数の型はバリアントになります。 それと、紛らわしいのは、共通モジュールに宣言してあるグローバルデータもあるのです。 だから、ソースモジュールの頭、関数の頭に宣言されてなくても、ローカルにいきなり作られた変数なのかグローバルな変数なのかがすぐには区別がつきません。 よって、各モジュールのグローバル変数、及びオブジェクト名一覧表を作り見比べながらソースを追いかけないといけないありさまでした。 そして、文字と数値の区別が曖昧なコーディングでもエラーが出ずに走ります。 Ｃ言語ではこんなコーディングできないよ〜〜〜。 もうひとつ、例えば Dim i,j As Integer と記述したら普通、iと jの Integerの変数が出来ると思ってしまいますよね。 ところが、この場合、j は Integerであっても i は Integerではありません。 多分バリアントでしょう。 私はＶＢであってもＣのように変数、関数の引数に型指定をするのでこれに気がつきました。 ★ それと、何かで見た記事ですが、あるＶＢプログラマが、Kylixを使ってみてフリーカーソルなのがいやだ。 というような事を書いていました。 フリーカーソルとは...？。 要は、Delphi、Kylixのエディタは普通のエディタと同じであるということです。 当たり前じゃないかと思われるでしょうがそうなんです。 当たり前の事なんです。 Delphi、Kylixは、実行時コンパイルして初めていろんなエラー等が出てきます。 これは、Ｃ言語等でのプログラム開発と同じです。 ところが、ＶＢは１行毎に、行単位で文法チェックを行ないます。 よって、文を途中まで打ち込んで、上の行からコピーしようと上に移動しようとすると文法エラーで怒られます。 変なところが律儀に出来ているという感じです。 初心者にはそのほうがいいのかもしれませんが...。 それと、ＶＢのエディタはＶＢ４までは関数単位でその中だけ見える様になっており、選択されてる関数の外が見えません。 つまり全体が見えないのです。 その関数がソースの先頭のほうにあるのか、最後のほうにあるのかも分かりません。 これが、フリーカーソルでない仕様なのでしょうか。？ カーソルで、ソースの頭から最後まで通して見るということは出来ません。 これも、初心者に余分なところを触らせない配慮だったのかもしれません。 で、目的のイベントハンドラや関数を探すときはエディタ上部のリストボックスから選択する仕様になっています。 これが、結果としてやたら長いソースになってしまう原因とも思われます。 その後、ＶＢ６ではその制限は外れました。 ★ 実行形式の速度なんですが、意図的に整数を指定して、整数演算のループ処理を行わせればネイティブコンパイラとしての速度が出ると思います。 が、変数の型を指定しなければバリアント型になるため速度がガクッと落ちます。 それと、実行形式プログラムとコントロールは、OLEの技術で連携してますのでコントロールとのデータのやり取り（もちろんバリアント型）が多いとこれも速度ダウンになります。 グリッドのコントロールとか使うと目に見えて遅いのが分かります。 ★ 結果としてＶＢの悪口みたいになってしまいましたが、まあ整数と実数の区別も曖昧な初心者プログラマには入りやすい言語であることは確かです。 また、マイクロソフトの製品であるため、ExcelやAccessとの 連携も非常にやりやすいのも事実です。 Excelのマクロ（VBA）はＶＢそのものという感じです。 小規模な、事務処理アプリ開発では、初心者でも使いこなせる小回りの利く便利な言語と言えるでしょう。 それと、ＶＢ用のコントロールを販売している会社も多いのでそれらの部品を購入して使ったほうが手っ取り早い。 という事で、ＶＢを使う企業では自社で部品を開発しようなんて考えないでしょう。 それと、寄らば大樹の陰でしょうか。？ ＶＢに傾倒している企業の管理者の方も多いような気がします。 私は、10数年 Ｃ言語をやってきた事、構造化や、Object指向等プログラミングの方法論に整然とした美学を感じているところがあるかもしれません。 それと、ライブラリを作るのが趣味みたいなところがあるからでしょう。 |
